DF-4581 — radeon_cs_parser_relocs: unchecked radeon_vm_get_bos() NULL return omits VM PD/PTs from the CS reservation set

Where

sys/dev/drm/radeon/radeon_cs.c:190-192:

if (p->cs_flags & RADEON_CS_USE_VM)
        p->vm_bos = radeon_vm_get_bos(p->rdev, p->ib.vm, &p->validated);

No NULL check. radeon_vm_get_bos() (sys/dev/drm/radeon/radeon_vm.c:128-138) returns NULL when its kvmalloc_array() fails — after having added nothing to &p->validated.

Consequence on failure

• VM page directory + page tables are missing from p->validated: never ttm_eu_reserve_buffers-reserved, never validated/pinned, and never fenced by ttm_eu_fence_buffer_objects (radeon_cs.c:427).
• Submission proceeds anyway: radeon_cs_ib_vm_chunk → radeon_bo_vm_update_pte (radeon_cs.c:565) → radeon_vm_update_page_directory builds a DMA IB writing PDEs at pd_addr = radeon_bo_gpu_offset(pd) — a BO whose placement is not held for this submission. Concurrent eviction can move the PD/PT BOs (their reservations are free) → the GPU writes PDEs at a stale address (freed/reused VRAM/GTT memory of another client), and the PTs can be evicted while the IB still executes. Race-grade GPU memory corruption, trigger-gated behind an allocation failure.

Reachability on this tree (important, honest caveat)

On DragonFly as compiled, kvmalloc_array(..., GFP_KERNEL) cannot return NULL: GFP_KERNEL = M_WAITOK without M_NULLOK (sys/dev/drm/include/linux/gfp.h:40), so failure panics or hangs instead (see DF-4580). The NULL path is therefore latent on DF today and a live upstream bug on Linux; it must be fixed together with any DF-4580 allocator-semantics fix, or fixing one bug silently activates the other.

Run

No runtime PoC is possible on the audit guest (no AMD GPU, no /dev/dri — radeon_cs_ioctl unreachable) and the NULL path cannot even be forced without allocator changes. DF-4581-trace.c documents the trace and the fix; verification is by code inspection only.

Expected result of the fix

radeon_cs_parser_relocs returns -ENOMEM when radeon_vm_get_bos fails, the ioctl unwinds via radeon_cs_parser_fini — no submission with an unreserved page directory.

DF-4581 VERDICT

Status: not_reproduced — code-proven defect, runtime-gated twice over (no AMD GPU on the guest; NULL path latent on DF as compiled).

Trace (by inspection, line-accurate)

1. radeon_cs_ioctl (sys/dev/drm/radeon/radeon_cs.c:655) → radeon_cs_parser_relocs (radeon_cs.c:90-201).
2. radeon_cs.c:190-192: p->vm_bos = radeon_vm_get_bos(...) — return ignored.
3. radeon_vm_get_bos (sys/dev/drm/radeon/radeon_vm.c:135-138): list = kvmalloc_array(...); if (!list) return NULL; — nothing has been added to head at that point (the first list_add is at radeon_vm.c:147).
4. Failure result: p->validated contains only the user reloc BOs. The VM page directory (vm->page_directory) and page-table BOs are never reserved by radeon_bo_list_validate (radeon_cs.c:196 → ttm_eu_reserve_buffers) and never fenced by ttm_eu_fence_buffer_objects (radeon_cs.c:427).
5. Submission continues: radeon_cs_ib_vm_chunk (radeon_cs.c:537) under vm->mutex → radeon_bo_vm_update_pte (radeon_cs.c:492) → radeon_vm_update_page_directory (radeon_vm.c) submits a DMA IB that writes PDEs at radeon_bo_gpu_offset(pd) — with the PD/PT BOs unreserved and unpinned for this CS, so a concurrent eviction (their reservations are not held) can relocate/free them → stale-address GPU writes + unsynchronized eviction mid-IB = GPU memory corruption.

Distinct from DF-4412: DF-4412 is a TOCTOU inside radeon_vm_get_bos (max_pde_used re-read racing GEM_VA, OOB write in radeon_vm.c's fill loop). DF-4581 is the unchecked NULL return at the radeon_cs.c:191 call site — different root cause, different file, different fix.

Why not reproduced on the guest

• Guest has no AMD GPU (pciconfig -l has no 1002: device; /dev/dri absent) → radeon_cs_ioctl unreachable at runtime.
• Even with the hardware, on DragonFly as compiled kvmalloc_array with GFP_KERNEL never returns NULL (M_WAITOK without M_NULLOK, sys/dev/drm/include/linux/gfp.h:40; see DF-4580's reproduced panic mechanism) — the NULL branch is latent until the allocator semantics are fixed (which is exactly when this missing check would become a live corruption race).

Impact ceiling

On a kernel where kvmalloc can fail (upstream Linux; DF after an M_NULLOK-style fix): race-grade GPU memory corruption behind an allocation failure — Medium-class, hardware- and race-gated. On DF today: latent.

Fix

One line + error unwind (fix.diff): check p->vm_bos == NULL → DRM_ERROR + return -ENOMEM; the ioctl's error path (radeon_cs_parser_fini(parser, r, false)) already unwinds correctly with an empty/partial validated list (relocs GEM refs are put at radeon_cs.c:435-443; kvfree(NULL) is a no-op).

Artifacts

• DF-4581-trace.c — annotated trace + fix
• fix.diff — git-apply-check-clean unified diff
• README.md, manifest.json, verdict.json

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.