DF-4580 — radeon_cs: uncapped num_chunks wired allocations; DF GFP_KERNEL failure = panic / eternal hang (local DoS)

What the finding is

radeon_cs_ioctl → radeon_cs_parser_init (sys/dev/drm/radeon/radeon_cs.c): two kernel allocations sized directly from the fully attacker-controlled __u32 drm_radeon_cs.num_chunks, with no upper bound:

• radeon_cs.c:287 — kcalloc(cs->num_chunks, sizeof(uint64_t), GFP_KERNEL) (chunk pointer array, 8·n bytes)
• radeon_cs.c:298 — kcalloc(p->nchunks, sizeof(struct radeon_cs_chunk), GFP_KERNEL) (24·n bytes)
• radeon_cs.c:346 — per-chunk kvmalloc_array(length_dw, 4, GFP_KERNEL) (4·length_dw bytes, length_dw also an uncapped u32)

On Linux, failure of these is a clean -ENOMEM. On DragonFly, the DRM port maps GFP_KERNEL to M_WAITOK | M_CACHEALIGN without M_NULLOK (sys/dev/drm/include/linux/gfp.h:40), and DF _kmalloc() therefore can never return NULL:

• type-limit exceeded → panic("%s: malloc limit exceeded") (sys/kern/kern_slaballoc.c:877; every malloc type's limit is physmem/10, kern_slaballoc.c:372)
• kernel_map full → panic("kmem_slab_alloc(): kernel_map ran out of space!") (kern_slaballoc.c:1724)
• pages unavailable → vm_wait() retry loop forever, unkillable thread (kern_slaballoc.c:1780-1806, sys/vm/vm_page.c:2927)

So an authenticated local DRM client on radeon hardware can, with a single CS ioctl:

• num_chunks ≈ 40–50 M → chunk-pointer array (≈330–400 MB) succeeds, next kcalloc trips the M_DRM type limit → deterministic kernel panic;
• num_chunks = 0xFFFFFFFF → first allocation asks for 32 GB → permanent uninterruptible hang of the calling thread (1 s vm_wait poll loop).

Latent aggravator (upstream-visible even where kcalloc can return NULL): radeon_cs_parser_fini then does for (i = 0; i < parser->nchunks; i++) kvfree(parser->chunks[i].kdata); (radeon_cs.c:447-448) — a NULL parser->chunks (after the radeon_cs.c:298-300 failure return) is dereferenced → second, independent crash path.

What this PoC does / does not do

The audit QEMU guest has no AMD/ATI GPU (pciconfig -l shows no 1002:xxxx device, /dev/dri does not exist), so radeon_cs_ioctl cannot be entered on it. This pack therefore verifies the sink mechanism the ioctl rides: df4580_limitpanic.c is a kld that performs the identical class of allocation (kmalloc(..., M_WAITOK|M_ZERO) — no M_NULLOK, own malloc type with the standard physmem/10 limit, exactly like M_DRM) until the limit trips.

Build / run (inside the guest as root)

cd /root/df4580 && make
kldload ./df4580.ko

Expected result

Serial console (see run.log, panic.txt):

df4580: malloc-type limit ~389 MB; looping kmalloc(32 MB, M_WAITOK|M_ZERO) [no M_NULLOK], GFP_KERNEL-equivalent
df4580: alloc #0 ... alloc #13 (type usage ~416 MB)
panic: df4580: malloc limit exceeded
_kmalloc() at _kmalloc+0xb09
df4580_modevent() at df4580_modevent+0xd8

The radeon trigger itself (single CS ioctl with crafted num_chunks) is code-traced in VERDICT.md; it needs radeon hardware.

DF-4580 VERDICT

Status: not_reproduced (full chain) — sink mechanism reproduced on guest (panic). Impact claimed: local kernel DoS (panic or unkillable hang).

Why the full chain did not run here

The finding's entry point is radeon_cs_ioctl (sys/dev/drm/radeon/radeon_cs.c:655), gated by rdev->accel_working (radeon_cs.c:662) — i.e. a bound, initialized radeon GPU. The audit guest (QEMU/KVM, DragonFly 6.5-DEVELOPMENT #0 X86_64_GENERIC) has no AMD/ATI PCI device and no /dev/dri (checked via pciconfig -l, ls /dev/dri); every radeon ioctl returns before the parser runs. That is a hard environment blocker for the ioctl itself, not a refutation: the code path is fully traceable and its allocation sink was exercised directly.

Code trace of the trigger (radeon hardware present)

1. Unprivileged-but-authenticated client (ioctl is DRM_AUTH|DRM_RENDER_ALLOW, sys/dev/drm/radeon/radeon_kms.c:912) issues DRM_IOCTL_RADEON_CS with num_chunks = N (u32, uncapped) and chunks pointing at N·8 bytes of user memory.
2. radeon_cs_parser_init radeon_cs.c:287: kcalloc(N, 8, GFP_KERNEL) → DF shim sys/dev/drm/include/linux/slab.h:44 kzalloc(N*8) → kmalloc(N*8, M_DRM, M_WAITOK|M_CACHEALIGN|M_ZERO).
3. With N ≈ 40–50 M on a 4 GB box (M_DRM limit = physmem/10 ≈ 389–405 MB): the 320–400 MB chunk-pointer array is allocated (wired, M_ZERO — feasible with >1 GB free RAM), pushing M_DRM.ks_loosememuse over the type limit; radeon_cs.c:298's kcalloc(N, 24, GFP_KERNEL) then enters _kmalloc and hits sys/kern/kern_slaballoc.c:877 → panic("M_DRM: malloc limit exceeded") — whole-system crash.
4. Alternative, N = 0xFFFFFFFF: first kcalloc requests 32 GB (64-bit multiply, no overflow in the DF shim); _kmalloc oversized path (kern_slaballoc.c:944-950) → kmem_slab_alloc(32 GB, M_WAITOK) → VA fits (kernel_map ≈ 8 TB) → page loop kern_slaballoc.c:1780-1806 vm_wait(0) = 1 s bounded sleep, retried forever since 32 GB > physmem; vm_wait sleeps with flags 0 (no PCATCH) → unkillable thread; repeatable per ioctl.
5. Latent cleanup crash: had the radeon_cs.c:298 kcalloc returned NULL (it does on upstream Linux where KMALLOC_MAX_SIZE forces a clean NULL for N > ~175 K), radeon_cs_parser_fini radeon_cs.c:447-448 derefs parser->chunks[i] with parser->chunks == NULL, nchunks > 0 → NULL-page read panic. On DF-as-compiled this is masked by the allocation panic itself (GFP_KERNEL cannot yield NULL); it becomes live the moment the port adds M_NULLOK semantics — fix both together.

Mechanism verification actually performed (this guest)

• Built kld df4580.ko (build.log) replicating GFP_KERNEL allocation semantics with its own malloc type (same physmem/10 limit rule).
• kldload → allocations #0..#13 (32 MB each, 416 MB cumulative ≥ 389 MB limit) → panic: df4580: malloc limit exceeded, backtrace _kmalloc() → df4580_modevent() (run.log, panic.txt).
• This proves both (a) the sink behavior radeon_cs.c:287/298/346 rides, and (b) that the Linux-shaped NULL return (and hence the parser_fini NULL-deref) is unreachable on DF until allocator flags change.
• Guest reset to with-src snapshot afterwards; module gone.

Exploit chain

DoS only: one ioctl → panic (or one unkillable thread per ioctl; threads are not bounded). No memory-corruption primitive identified in this path.

Fix

Cap num_chunks and per-chunk length_dw at sane maxima before allocating in radeon_cs_parser_init, and make radeon_cs_parser_fini NULL-safe (see fix.diff). Suggested caps mirror upstream practice (chunks are at most a handful; 64 is generous, length_dw ≤ 1 M dwords).

Artifacts

• df4580_limitpanic.c / Makefile — sink-mechanism kld (source of record)
• build.log — untrimmed guest build output
• run.log, panic.txt — serial console capture of the run + panic backtrace
• env.txt — guest uname/physmem/compiler
• fix.diff — proposed fix (authored post-verification; never applied to sys/)

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.