DF-4914 VERDICT — REPRODUCED (UAF / double-free; impact: kernel memory corruption, DoS)

Finding

radeon_fbdev_init() (sys/dev/drm/radeon/radeon_fb.c:357-407):

• :374 kzalloc's struct radeon_fbdev,
• :379 stores it into rdev->mode_info.rfbdev before anything that can fail (its own comment-free sequencing),
• on every failure (drm_fb_helper_init :384-387, single_add_all_connectors :389-391, initial_config :396-398) runs fini: drm_fb_helper_fini(...) → free: kfree(rfbdev); (:405) without clearing rdev->mode_info.rfbdev.

The only place the pointer is cleared is radeon_fbdev_fini() (:417) — i.e. AFTER radeon_fbdev_destroy() already used it. Meanwhile radeon_modeset_init() ignores the init failure entirely (radeon_display.c:1640 radeon_fbdev_init(rdev); — no return check), so the driver stays loaded with a dangling mode_info.rfbdev and every later consumer — radeon_fbdev_fini() (radeon_display.c:1655, driver unload / device unplug / reboot), radeon_fbdev_robj_is_fb() (radeon_fb.c:427-435, called from BO validation/eviction), radeon_fb_{add,remove}_connector() (hotplug) — dereferences freed memory.

The double free: radeon_fbdev_fini() :415 kfree(rdev->mode_info.rfbdev) on the block already freed at :405.

Reproduction (2026-09-25, guest DragonFly 6.5-DEVELOPMENT #0 X86_64_GENERIC)

Production modules: stock /boot/kernel/drm.ko + /boot/kernel/radeon.ko (no radeon GPU present; module load needs no hardware). PoC module rfbuaf.ko drives the REAL radeon_fbdev_fini() from the loaded module.

Stage 1 (state injection of the exact failed-init state — radeon_fb.c:374-405):

rdev->mode_info.rfbdev = 0xfffff8011788c900 — kfree()d block still recorded (dangling)

Stage 2 (production teardown on the dangling pointer) — deterministic panic:

panic: memory chunk 0xfffff8011788c900 is already free!
chunk_mark_free() at chunk_mark_free+0xae
_kfree() at _kfree+0x262
radeon_fbdev_fini() at radeon_fbdev_fini+0x78        ← radeon_fb.c:415
sysctl_run() at sysctl_run+0x1c4

Stage 3 (freed block reclaimed by an ordinary same-size allocation, filled with 0x41; production teardown) — UAF with fully controlled data:

DF-4914: reclaim attempt: 0xfffff801179c4440 (dangling 0xfffff801179c4440, RECLAIMED)
DF-4914: reclaimed block 0x41-filled (fb.obj[0]=0x4141414141414141)
Fatal trap 9: general protection fault while in kernel mode
Stopped at radeonfb_destroy_pinned_object+0x1c: movl -0x2d0(%rdi),%eax

rdi is gem_to_radeon_bo(0x4141414141414141) — the teardown consumed the attacker-reclaimed block's fields inside production radeon code. Whoever can reclaim the ~1.2KB slab block between driver-load failure and teardown (any same-size kernel allocation under attacker influence) controls the object the kernel walks and double-frees.

Why the failure is realistic on hardware

• drm_fb_helper_init/-ENOMEM under memory pressure at driver load;
• initial_config → radeonfb_create failure — classically VRAM exhaustion during fbcon object creation on small-VRAM cards (the code even special cases ≤8MB/≤32MB cards at :367-372) — feeding DF-1969's leak family the same entry;
• after the failure, radeon_modeset_init continues (:1640 ignores the error) — the panic/corruption is DEFERRED to unload/reboot/hotplug, a long-lived window in which the freed block is reused by unrelated kernel activity.

Impact ceiling

Kernel heap corruption: double free (deterministic slab panic or freelist corruption on builds without the debug detector) plus use-after-free with attacker-influenced contents (stage-3 wild chase starts from a fully controlled fb->obj[0]). Turning this into code execution requires the load-time failure to be induced (OOM/VRAM pressure on a system with a radeon GPU) and slab reuse engineering — plausible for a local attacker with long-lived access, not weaponized here. Severity: Medium (memcorrupt); CVSS context: local, requires GPU + load-time resource exhaustion.

Fix validation

fix.diff: one line — rdev->mode_info.rfbdev = NULL; at the free: label (covers both fini: and free: falls-through). Validated: guest /usr/src (md5-identical to the audited tree) patched, make -j6 in /usr/src/sys/dev/drm/radeon → BUILD=0, fixed module loads and runs (fix_build.log, run.log tail). Dynamic baseline-vs-patched re-run of the PoC is not possible on this guest: the failure ENTRY (a graceful radeon_fbdev_init error) cannot be produced live without a radeon GPU — the in-guest allocators only fail catastrophically (oversized kcalloc wedges in M_WAITOK paging; observed before the PoC was restructured to state injection), and the PoC's stage 1 injects the post-failure state directly, so patched-module stages 2/3 would be unchanged by construction. Classification: fix_status=not_testable (compile + load validated; behavior follows by inspection from the trace the PoC verified: store at :379, un-cleared free at :405, second free at :415).

PoC changes vs the initial seed

Initial draft called radeon_fbdev_init() directly on the fake rdev; the forced-ENOMEM via num_crtc=0x20000000 kcalloc wedged the guest in M_WAITOK paging (pagedaemon "Continuous paging") instead of failing, and the num_crtc=0/disconnected-connector routes turned out to succeed (-EAGAIN is converted to deferred-setup success in this tree's drm_fb_helper). Restructured to documented state injection of the exact :374-405 sequence. Also fixed the DFly DECLARE_MODULE usage (moduledata_t required — first load GPF'd in module_register/strcmp because the handler function was passed instead).

Guest hygiene

Guest left state: /root/rfb (PoC), /root/fix.diff applied to /usr/src/sys/dev/drm/radeon/radeon_fb.c + rebuilt radeon.ko there; vm.sh reset with-src performed at the end of the run.

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.