# DF-5126 VERDICT — no-op read side + fixed 1s delay line

## Status: REPRODUCED (deterministic 3/3 per run; RIP control; fix validated)

## Root cause

* `sys/dev/drm/include/linux/rcupdate.h:46-56`: `rcu_read_lock()`/`rcu_read_unlock()`
  map to `preempt_disable()`/`preempt_enable()`.
* `sys/dev/drm/include/linux/preempt.h:37-38`: those map to `cpu_ccfence()` —
  a compiler reordering fence only (sys/cpu/x86_64/include/cpufunc.h:219-227).
  No crit section, no preemption exclusion, no assertion preventing a thread
  from blocking inside the section.
* `sys/dev/drm/linux_rcu.c:79-105,161-184`: reclamation is a per-CPU ring whose
  entries fire after `delta >= hz` — a *fixed one-second timer*, with no
  coupling to readers whatsoever.

Therefore any read-side critical section that survives longer than the delay
(stalled, preempted, or blocked — all permitted by the shim) has its object
freed underneath it by the shipped `__kfree_rcu()`/`call_rcu()` path.

## Runtime proof (stock /boot/kernel/drm.ko, 6-CPU guest)

Stage B of the harness (writer cpu0 / reader cpu2; `__kfree_rcu` is the REAL
drm.ko symbol; victim allocated/freed with the shim's own `kzalloc`/`kfree`
(M_DRM) so slab zones match):

1. reader: `rcu_read_lock(); v = rcu_dereference(gp); tsleep(2s); read v->magic; rcu_read_unlock();`
2. writer: `rcu_assign_pointer(gp, NULL); __kfree_rcu(v1); tsleep(1.4s); [32-object poison reclaim spray]`
3. The shim's timer (`drm: expand RCU cpu 0 to 16` in dmesg — the real ring)
   frees v1 at ~+1s — well inside its own grace model — while the reader is
   provably still inside its critical section.
4. Reader wakes at +2s, still in-section: reads MAGIC_POISON and calls
   `v->v_fp` — a function pointer that exists only as data written into the
   freed-and-reclaimed object.

Results: 3/3 rounds, every baseline run (runs 1, 2, 3 and the extra trigger
rounds). With `rip_panic=1` the reclaimed fp = 0xffffffff52170000 and the
kernel took `Fatal trap 12: page fault ... instruction pointer = 0xffffffff52170000`
(panic.txt) — arbitrary kernel RIP control from the UAF.

## Distinguishing from neighbors

* DF-5033 (amdgpu_bo_list.c): lockless `idr_find()` vs *synchronous* kfree in
  `idr_grow()` — a different subsystem and an immediate free; that finding
  cites linux_rcu.c:187 only as context. This finding is about the RCU shim's
  own grace-period model (delay line + no-op read side) and is demonstrated
  through the shim's exported `__kfree_rcu`.
* DF-1881 (linux_fence.c/reservation): a specific unsafe refcount helper; not
  the shim's grace model.

## Exploit chain / ceiling

Identical to DF-5125's (same object, same reclaim discipline): blocked/preempted
reader -> `__kfree_rcu` fires at +1s -> reclaim with controlled content ->
reader consumes poisoned fields -> indirect call through reclaimed fp ->
RIP control (fatal trap shown). Real-world ceiling: every drm kfree_rcu/call_rcu
victim reachable from unprivileged GPU clients (fences, bo lists, gem objects,
reservation arrays). This guest has no GPU/render node, so the shipped call
sites cannot be driven end-to-end here — environment blocker, documented; the
primitive (UAF + RIP control via the shipped shim) is fully reproduced.

## Fix validation

`fix.diff` (shared with DF-5125): `rcu_read_lock()`/`rcu_read_unlock()` now
maintain a global nesting counter (`rcu_read_acquire`/`rcu_read_release`);
`rcu_timer()` defers element execution while `rcu_readers != 0`; the blocked
reader therefore holds off the free until after its unlock — exactly the
semantics RCU promises. Post-fix stage B: **0 hits in 6 rounds** (including
`rip_panic=1` trigger rounds), guest healthy. Baseline was 3/3 every 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.