DF-5008 Verification Verdict

Finding: amdgpu_vram_mgr_new() nodes[] out-of-bounds write via non-power-of-two mem->page_alignment Severity: High · Impact class: kernel heap OOB write (memcorrupt) Verification method: in-kernel harness executing the verbatim driver loop against the real in-kernel drm_mm + kvmalloc on a custom drm-enabled guest kernel, plus a userspace arithmetic sweep. The amdgpu entry point is hardware-gated (no AMD GPU in QEMU; amdgpu binds only on real ASICs), but every instruction of the defect — the bound computation and both insert loops — ran unmodified in kernel space.

Verdict: REPRODUCED (kernel-space primitive; hardware-gated entry)

How the chain was proven

1. Reachability of the attacker input (static, path:line-exact): AMDGPU_GEM_CREATE is unprivileged on render nodes (amdgpu_kms.c:1197 DRM_AUTH|DRM_RENDER_ALLOW); args->in.alignment flows amdgpu_gem.c:260 → amdgpu_gem.c:58 (no power-of-two check — the only clamp is < PAGE_SIZE) → amdgpu_object.c:434 (roundup(3MB, PAGE_SIZE) >> PAGE_SHIFT = 768, non-p2 preserved) → ttm_bo.c:1247 → ttm_bo.c:1099 → amdgpu_vram_mgr.c:183-185 (pages_per_node = max(512, 768) = 768, non-p2) → num_nodes = DIV_ROUND_UP(768, 768) = 1 → loop 1 (:201-215) inserts nodes[0] with rounddown_pow_of_two(768) = 512 pages; pages_left = 256 → loop 2 (:217-235) inserts &nodes[1] — out of bounds.

2. The sink really writes there (kernel, real drm_mm): S1 — the real drm_mm_insert_node_in_range() wrote a live node at nodes[1] of a 1-element kvmalloc_array (run.log): start=768 size=256 allocated=1 color=0 mm=0xfffff8011845f668 hole_size=1047552. sizeof(struct drm_mm_node) = 184 on this build, so this is a 184-byte write starting at byte offset 184 of a 184-byte allocation.

3. It corrupts foreign objects (kernel, groomed): S2 — with the exact-size array allocated into a hole between sprayed M_DRM neighbors, the OOB node clobbered neighboring object #17 across 13 machine words, including kernel text/heap pointers (0xfffff8008da72040) and partial-word residue (0xaa55aa5500000001) — cross-object heap corruption in a stock kernel allocator zone (run.log).

4. The arithmetic is general (userspace model): every non-p2 alignment

   2 MB (i.e. exceeding default amdgpu_vram_page_split = 512 pages) with size == alignment overflows by exactly one node; every p2 alignment is safe; alignments ≤ 2 MB are absorbed by the p2 default split (model_run.log). Loop 2 provably runs ≤ 1 iteration (its body zeroes pages_left), so the overflow is exactly one node — 184 bytes — past the array, linked into the live mm.

5. Amplitude/trigger characterization: first allocation on a fresh VRAM mm succeeds deterministically (hole starts at page 0; 0 % 768 == 0; second insert lands at 768..1024 — needs only ≥ 4 MB VRAM). Repeatable per ioctl; content semi-controlled (start/size attacker-steerable, kernel pointers in the rest); the OOB node stays linked in mgr->mm lists until amdgpu_vram_mgr_del() removes it (a second OOB write of the same struct) and kvfrees the array.

Why not uid=0 / panic on this guest

amdgpu.ko builds cleanly as a loadable module on DragonFly (confirmed: fix_build.log/DRMTEST build compiled the whole driver, rc=0) but only binds on AMD ASICs; the QEMU guest has none (std-VGA), so the ioctl→driver path cannot be entered here. Escalation to uid=0 on real hardware is the expected outcome class for a repeatable 184-byte semi-controlled kernel-heap overflow with linked-list/rbtree kernel-pointer writes (classic slab-groom → victim object → credential overwrite), but was not demonstrated — stated explicitly rather than claimed.

Fix validation

• fix.diff clamps pages_per_node to a power of two (rounddown), which restores the loop-1 ≥ pages_per_node invariant so num_nodes is again a true upper bound (loop 2 ≤ 1 node, proven).
• Behavioral: harness S3 ran the fixed loop with the real drm_mm — no write beyond num_nodes (run.log SUMMARY S3=0), while the unfixed loop (S1/S2) corrupts (S1=1 S2=1).
• Compile: fix applied inside the guest's /usr/src copy; the amdgpu module rebuilt with -Werror, rc=0 (fix_build.log: amdgpu_vram_mgr.o line 149, amdgpu.ko relink line 781). The workspace sys/ tree was not modified.
• Guest reverted to the clean with-src snapshot afterwards.

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.