DF-4506 — i915_gem_context unlocked IDR lookups vs idr_grow kfree (UAF read)

What this pack proves

sys/dev/drm/i915/i915_gem_context.c resolves user context handles with no lock at all:

• destroy ioctl: i915_gem_context_lookup() at i915_gem_context.c:831 (struct_mutex only acquired afterwards at :835)
• getparam :855, setparam :901 (never take struct_mutex)
• reset_stats :981 (__i915_gem_context_lookup_rcu under bare rcu_read_lock())

On Linux this is safe because IDR reads are RCU-protected. On DragonFly:

• rcu_read_lock() is cpu_ccfence() — a no-op with no grace period (sys/dev/drm/include/linux/rcupdate.h:46-50, sys/dev/drm/include/linux/preempt.h:33)
• idr_find() takes no token (sys/libkern/linux_idr.c:515-528)
• idr_grow() — reached from the same file's create path (i915_gem_context.c:355 idr_alloc when the 255-entry array is full) — swaps in a new node array and kfrees the old one synchronously (sys/libkern/linux_idr.c:449-459)

=> a lockless idr_find() that loaded idp->idr_nodes before the swap dereferences freed memory after the swap. If the freed 4080-byte array is re-groomed with controlled contents, idr_find hands the ioctl an attacker-crafted struct i915_gem_context *, which flows into kref_get_unless_zero (refcount write), and on the destroy path into context_close() → set_bit on ctx->flags, list_del_init on ctx->hw_id_link (unlink writes), lut_close() radix/list walks — i.e. fully pointer-driven kernel write primitives.

The i915 ioctl surface itself needs Intel GPU hardware (the audit guest has only virtio-vga), so the PoC reproduces the vulnerable pattern directly against the same shim primitives the ioctls use.

Files

• idr_race.c + Makefile — KLD reproducer (producer = fill+grow+canary, consumer = lockless idr_find, detector for the 0xAA canary pointer)
• amplifier.diff — guest-only instrumentation: sysctl-gated tsleep between idr_find's node-pointer load and its dereference. Enables an interleaving the uninstrumented code already permits (loads are unordered plain C); default off.
• fix.diff — the real fix: defer the kfree of old/destroyed node arrays by 1s via callout, mirroring the shim's own kfree_rcu() delay-line convention (sys/dev/drm/linux_rcu.c).
• build.sh, run.sh — exact commands.
• build.log, run.log, run.stress.log, run.fixed.log — untrimmed logs.
• VERDICT.md, manifest.json, verdict.json — outcome.

Reproduce

On the guest (amplifier kernel installed):

sh build.sh            # builds idr_race.ko
sh run.sh              # amplified: expect CAPTURE; native: expect none

Fix validation: restore pristine linux_idr.c, apply amplifier.diff + fix.diff, rebuild kernel, reinstall KLD, rerun run.sh — captures must stay 0 while conditions are otherwise identical.

DF-4506 VERDICT

Finding

sys/dev/drm/i915/i915_gem_context.c resolves user-supplied context handles with no lock at all — destroy :831 (struct_mutex acquired only at :835, after the lookup), getparam :855, setparam :901 (neither ever takes struct_mutex), and reset_stats :981 (bare rcu_read_lock()). On Linux this is safe because IDR reads are RCU-protected. On DragonFly the entire safety fiction collapses:

• rcu_read_lock() == preempt_disable() == cpu_ccfence() — a no-op with no grace period (sys/dev/drm/include/linux/rcupdate.h:46-56, sys/dev/drm/include/linux/preempt.h:33);
• idr_find() takes no token (sys/libkern/linux_idr.c:515-528);
• idr_grow() — reached from this very file's create path (i915_gem_context.c:355 -> idr_alloc() when the 255-entry array is full — swaps in a new node array and kfrees the old one synchronously (sys/libkern/linux_idr.c:449-459).

A reader that loads idp->idr_nodes before the swap dereferences freed memory after the kfree. The freed 4080-byte array is prime grooming material: if re-allocated with controlled contents, idr_find() hands the ioctl an attacker-crafted struct i915_gem_context *, which flows into kref_get_unless_zero(&ctx->ref) (refcount write at controlled offset) and, on the destroy path, into context_close() -> set_bit on ctx->flags, list_del_init(&ctx->hw_id_link) (unlink write primitive), lut_close() list/radix walks on controlled pointers — i.e. pointer-driven kernel write primitives from an unprivileged render-node user.

This is beyond the known DF-1662 (destroy-vs-destroy double-close): here no double anything is needed — one ordinary create racing one ordinary lookup ioctl suffices, because the locking assumption the code inherits from Linux (RCU-safe IDR) does not exist on DragonFly.

Verification (guest: DragonFly 6.5-DEVELOPMENT, 6 vCPU, no i915 GPU)

The guest has virtio-vga only, so the i915 ioctl surface itself cannot run. The PoC therefore drives the same primitives the ioctls use — idr_init/idr_alloc/idr_find/idr_destroy — from a KLD (idr_race.c), with a producer thread that fills the idr to the grow threshold, triggers the grow (kfree of the old array) and immediately re-allocates the freed size-class filled with a 0xAA canary, racing a consumer thread doing lockless idr_find().

1. Amplified (guest-only sysctl-gated tsleep between idr_find's node-pointer load and its dereference — an interleaving the uninstrumented code already permits; the amplifier only widens a ~2-5ns window): 20/20 and 9/10 rounds returned the canary pointer 0xAAAAAAAAAAAAAAAA — idr_find() returned a pointer crafted by the re-allocation of the freed array. Controlled UAF read proven.
2. Native, no amplifier: 500-round stress with a concurrent reader -> kernel panic: Fatal trap 12 ... Stopped at idr_find+0x48: movl 0x8(%rbx),%edx, fault VA 0xc88 == nodes[200].allocated off a stale pointer (panic.txt). The race window is practically winnable without instrumentation.
3. Fix validation (fix.diff: defer the kfree of replaced/destroyed node arrays by 1s via callout, mirroring the shim's own kfree_rcu delay-line convention in sys/dev/drm/linux_rcu.c): rebuilt kernel with identical amplifier conditions -> 0 captures, 0 anomalies; 3x native stress with 1,598,684 finds -> no panic, guest alive (run.fixed.log).

Bottom line

• Root cause certain, race demonstrably reachable at native stress rates (panic), controlled-pointer UAF read demonstrated under amplification.
• Demonstrated impact on this guest: kernel panic. In the real i915 path (Intel GPU present, unprivileged render node) the same primitive yields an attacker-influenced i915_gem_context * consumed by write-heavy close/destroy logic — a memory-corruption escalation path; the full chain to uid=0 was not assembled because the audit guest has no Intel GPU.
• fix.diff is validated: baseline reproduces (captures + panic), patched kernel is clean under the same conditions.

Cross-references

• DF-1662 (pass 1): destroy-vs-destroy double-close refcount underflow — distinct bug, same ioctl; both are fixed/hardened by serializing lookups.
• DF-4444 (i915_vma drm_vma_node_unmap no-op): orthogonal; contexts' lut_close only drops object refs — no additional interaction found (i915_gem_context.c:97-116 vs i915_vma.c).

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.