DF-4412 — radeon_vm_get_bos() TOCTOU on vm->max_pde_used → heap OOB write

File: sys/dev/drm/radeon/radeon_vm.c (pass 2, GLM 5.3)

Build

On a DragonFly guest with the kernel source tree:

cc -O2 -Wall -pthread -o /tmp/trigger_race DF-4412/trigger_race.c
# radeon_abi.h must sit next to the .c (self-contained UABI definitions)

Run

/tmp/trigger_race

Requires a cayman-or-newer radeon KMS device (/dev/dri/card0 with vm_manager.enabled, i.e. Radeon HD 6900 "Cayman" / Trinity / SI / CIK class). The racy loop retries with a fresh drm fd each round.

Expected result on capable hardware

Kernel heap corruption: the list[idx] writes and the list_add() in radeon_vm_get_bos() (radeon_vm.c:149-160) run past the kvmalloc_array(vm->max_pde_used + 2, …) allocation (radeon_vm.c:135) whenever a concurrent RADEON_GEM_VA ioctl on the same drm fd grows vm->max_pde_used between the allocation and the loop's live re-read of the bound. Expected outcome after enough rounds: kernel panic / slab corruption, or silent corruption of adjacent heap objects (each overflow slot writes ~5 kernel pointers and links &list[idx].tv.head into a live list).

Observed on THIS audit guest

/dev/dri does not exist — the QEMU guest has only the std VGA device (vgapci0 0x1234:0x1111), no radeon GPU. The trigger compiles and runs, and exits at open("/dev/dri/card0") with ENOENT. Runtime verification of the race requires radeon hardware that this guest does not have; the finding is proven by source trace (see VERDICT.md).

DF-4412 — VERDICT

status: not_reproduced (hardware absent) — finding stands by line-level trace; not a false positive

Root cause (certain, by trace)

radeon_vm_get_bos() allocates its array once from a snapshot of vm->max_pde_used, then uses a live re-read of the same field as the loop bound:

• sys/dev/drm/radeon/radeon_vm.c:135 — kvmalloc_array(vm->max_pde_used + 2, sizeof(struct radeon_bo_list), GFP_KERNEL) (bound read #1)
• sys/dev/drm/radeon/radeon_vm.c:149 — for (i = 0, idx = 1; i <= vm->max_pde_used; i++) (bound re-read every iteration; the list_add() call and the stores through list[idx].robj inside the body force the compiler to reload vm->max_pde_used — they may alias vm)
• sys/dev/drm/radeon/radeon_vm.c:153-159 — list[idx].robj = …; … list_add(&list[idx++].tv.head, head); — the OOB writes once idx passes the allocated element count

vm->max_pde_used is grow-only and updated under vm->mutex in radeon_vm_bo_set_addr():

• radeon_vm.c:535-536 — if (eoffset > vm->max_pde_used) vm->max_pde_used = eoffset;
• radeon_vm.c:573-574 — vm->page_tables[pt_idx].bo = pt; (PTs appear one at a time after the bump)

Neither caller of radeon_vm_get_bos() holds vm->mutex:

• sys/dev/drm/radeon/radeon_gem.c:569 (radeon_gem_va_update_vm) — mutex_lock(&bo_va->vm->mutex) only happens at radeon_gem.c:583, after get_bos
• sys/dev/drm/radeon/radeon_cs.c:191 (radeon_cs_parser_bos) — the vm mutex is taken much later at radeon_cs.c:564

Race layout

Thread T2 (CS or GEM_VA on fd F) calls get_bos while thread T1 (GEM_VA on the same fd F, same radeon_vm) maps a BO near the top of the VA space:

1. T2: kvmalloc_array(0 + 2, 48) → 2-element array (fresh vm, max_pde_used == 0 because only a low mapping exists)
2. T1: vm->max_pde_used = 4095 + starts filling vm->page_tables[i].bo one by one (default vm_size=8 → max_pfn = 8<<18 = 2M PFNs → 4095 PDEs at block_size 9)
3. T2: loop bound now evaluates i <= 4095; every non-NULL page_tables[i].bo writes list[idx++] → up to ~4096 slots × 48 bytes ≈ 190 KB past a 2-element allocation, each slot containing kernel pointers and an in-list list_head.

vm->max_pde_used never shrinks, so each round needs a fresh drm fd (attacker opens/closes /dev/dri/card0 — every open creates a fresh radeon_vm with max_pde_used == 0). Attacker retries unboundedly.

Why not reproduced here

This QEMU guest has no radeon GPU (/dev/dri absent; the only VGA device is the emulated 0x1234:0x1111 std VGA — see env.txt). The trigger builds cleanly (gcc 8.3, DF 6.5-DEVELOPMENT, see build.log) and runs; it exits at open("/dev/dri/card0"): ENOENT (run.log). The race itself needs a cayman+ radeon device with KMS, which no QEMU target can provide (no radeon emulation exists upstream in QEMU).

Not a false positive: every element of the chain is unconditional source fact; the only untested quantity is the race window, which is a timing property, not a correctness one. Severity High (kernel heap OOB write from an unprivileged DRI client), exploitability "likely".

Exploit chain (sketch, if the class permits)

win race → OOB write of struct radeon_bo_list slots ({struct radeon_bo *robj; u32 preferred, allowed; struct ttm_validate_buffer tv {struct ttm_buffer_object *bo; struct list_head head; bool shared}; u64 tiling_flags}) plus list_add() of an OOB list_head into p->validated → corrupt adjacent slab objects (on DFly, kvmalloc_array → kmalloc → kmalloc zones) → target a zone-mated victim object (e.g. file/proc structures) → forged pointer / refcount pivot → uid=0. The written values are partially attacker-influenced (bo domain bits, bo kernel pointers).

Recommended fix

Snapshot the bound into a local before allocating (no lock needed, kills the TOCTOU). See fix.diff.

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.