DF-4357 — AMDGPU_INFO_READ_MMR_REG missing upstream count cap (Low, hardening)

Build / Run / Expected

cc -O2 -o trigger trigger.c
./trigger /dev/dri/renderD128     # unprivileged, needs an AMD GPU
# vulnerable kernel: iterations print ENOMEM (512MiB kmalloc attempted)
#                    or EFAULT-after-alloc
# patched kernel  : iterations print EINVAL instantly (count > 128 cap)

This audit's QEMU guest has no AMD GPU and no /dev/dri — runtime half is hardware-gated; see VERDICT.md.

Bug

amdgpu_kms.c:668-684 (AMDGPU_INFO_READ_MMR_REG): user-controlled info->read_mmr_reg.count (u32) goes straight into kmalloc_array(count, 4, GFP_KERNEL) with no upper bound. Upstream Linux (v5.4, and every release since the cap landed) begins the same block with:

        if (info->read_mmr_reg.count > 128)
            return -EINVAL;

The DF tree's amdgpu port is a ~v5.0 base (verified: v5.0 upstream also lacks the cap) and never received it.

Consequences without the cap: * per-call kernel allocation of count*4 bytes attempted from an unprivileged render client (bounded only by allocation failure; the alloc_size unsigned truncation at count >= 2^30 additionally requires a successful >= 4 GiB kmalloc, which DF's malloc(9) will happily attempt with M_WAITOK semantics, stalling the caller and pressuring kernel memory); * the register-read loop runs one allowlist check + MMIO read per dword — in practice it bails at the first disallowed offset, so the loop-DoS is self-limiting; the allocation pressure is the real (weak) DoS vector.

This is a hardening/DoS-low finding, not memory corruption: all copies are min(size, alloc_size)-bounded and the loop cannot overrun regs.

Fix

fix.diff — add the upstream cap verbatim.

DF-4357 VERDICT — READ_MMR_REG count cap missing (Low, hardening)

Status: INCONCLUSIVE (hardware-gated). Divergence: certain. Runtime: not executed (guest has no AMD GPU, no /dev/dri, no amdgpu_drm.h UAPI header — all verified on the guest, see run.log / env.txt).

Source certainty

• DF amdgpu_kms.c:668-684: no bound on info->read_mmr_reg.count before kmalloc_array(count, sizeof(*regs)=4, GFP_KERNEL).
• Upstream v5.4 (fetched this session) has if (count > 128) return -EINVAL; immediately before the same kmalloc. Upstream v5.0 (the DF base) also lacks it — so this is a "never-received-later-hardening" gap, not a port regression.
• Not memory corruption: the loop writes only within the successfully allocated regs (allocation failure => -ENOMEM), and the copy-out is min(size, alloc_size). The alloc_size (unsigned) truncation at count >= 2^30 cannot produce an OOB because the copy uses the same truncated value and the loop is bounded by the successful allocation.
• Practical abuse = unprivileged render client forcing repeated large-kmalloc attempts (M_WAITOK stall / kernel memory pressure) — Low.

Why not higher severity

The per-dword allowlist check (amdgpu_asic_read_register) rejects any consecutive run of unlisted offsets on the first iteration, so the MMIO loop self-terminates almost immediately; only the allocation side is abusable, and equivalent (larger, legal) allocation pressure is available to the same user via GEM_CREATE anyway.

Runtime evidence on this guest

• ls /dev/dri* -> No such file or directory (no DRM device nodes)
• cc hdrtest.c including -> fatal error: no such file
• pciconf shows no vendor 0x1002 device

Fix

fix.diff adds the upstream cap (apply-check OK on guest's pristine /usr/src; compile-validated by the patched buildkernel — see fix_build.log evidence in the shared /tmp/kbuild.log excerpt recorded in this pack).

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.