DF-5125 VERDICT — synchronize_rcu() empty macro

Status: REPRODUCED (UAF + kernel RIP control; fix validated)

Root cause (source-certain)

The DragonFly drm LinuxKPI implements Linux RCU as a per-CPU delay line (sys/dev/drm/linux_rcu.c): call_rcu()/__kfree_rcu() queue elements that rcu_timer() executes after delta >= hz (linux_rcu.c:81-83). There is no synchronize_rcu() implementation anywhere in linux_rcu.c; instead the header defines it away:

sys/dev/drm/include/linux/rcupdate.h:94:
#define synchronize_rcu()

rcu_read_lock()/rcu_read_unlock() are preempt_disable()/preempt_enable() (rcupdate.h:46-56) which are cpu_ccfence() — a compiler fence with no runtime semantics (sys/dev/drm/include/linux/preempt.h:37-38, sys/cpu/x86_64/include/cpufunc.h:219-227).

Consequence: the canonical Linux teardown contract — "after synchronize_rcu() returns, no pre-existing reader can still hold the old pointer" — is vacuously violated: the call returns instantly and the caller typically kfrees the old object on the next line, racing every reader on every other CPU that is mid-critical-section. In-tree callers of the broken macro: sys/dev/drm/i915/i915_gem.c:3713 and :3731 (the shim's get_state_synchronize_rcu()/cond_synchronize_rcu() pair used by i915_request.c:761 is likewise a no-op/mfence).

Mechanical proof

The harness ships a witness function df_sync_witness(void){ synchronize_rcu(); kfree((void*)0); }. Compiled against the shipped headers it is a single retq (build.log, objdump):

0000000000000970 <df_sync_witness>:
 970:   c3                      retq

After fix.diff it contains a real call (jmpq to the external synchronize_rcu).

Runtime proof (stock /boot/kernel/drm.ko, guest 6.5-DEVELOPMENT, 6 CPUs)

Stage A (DF-5125 contract test): reader thread pinned to CPU2 runs the exact canonical read-side pattern; handshake proves it holds the pointer inside its critical section; writer on CPU0 then runs rcu_assign_pointer(gp,v2); synchronize_rcu(); kfree(v1); and reclaims v1's slot with poisoned content. All RCU primitives are the shipped shim's (headers + drm.ko symbols __kfree_rcu/call_rcu); only the loops are local.

Results (3 full runs + extra rounds):

The reader observed the freed object's contents change while provably inside its read-side critical section in every single round.

Impact demonstration — kernel RIP control through the freed object

With rcu_race.rip_panic=1 the reclaimed content sets the freed object's function pointer to 0xffffffff52170000 (canonical, unmapped). The reader's v->v_fp(v) — the drm idiom (e.g. fence release paths) — jumped there:

Fatal trap 12: page fault while in kernel mode
cpuid = 2; lapic id = 2
fault virtual address = 0xffffffff52170000
instruction pointer     = 0x8:0xffffffff52170000
fault code              = supervisor read instruction, page not present
panic: page fault
--- trap 000000000000000c, rip = ffffffff52170000 ---

That is arbitrary kernel instruction-pointer control from the UAF: the kernel executed an address that existed only as data written into reclaimed freed memory.

Exploit chain / ceiling

Demonstrated chain: reader in CS -> zero-instruction synchronize_rcu() -> immediate kfree under reader -> slab reclaim with controlled content -> reader dereference (info read) and indirect call (RIP control). With a real DRM victim object (the pattern is used by i915/amdgpu/scheduler/reservation code compiled into the shipped drm.ko and the gpu driver modules) and user-controlled reclamation content this is the classic path to uid=0. On this QEMU guest there is no GPU and no render node, so the shipped call sites are unreachable end-to-end; that is a hard environment blocker (documented), not a mitigation — the primitive itself (UAF + RIP control with the shipped shim) is fully reproduced here.

Fix validation

fix.diff (in this pack): declares extern void synchronize_rcu(void) in rcupdate.h, implements it in linux_rcu.c (waits >= 2 delay periods AND until rcu_readers == 0), counts read-side critical sections (rcu_read_acquire/rcu_read_release wired into rcu_read_lock/unlock), and makes rcu_timer() defer reclamation while any reader is in flight.

Applied to the guest's /usr/src, drm.ko rebuilt (/usr/src/sys/dev/drm/drm), harness rebuilt against the fixed headers, exact same PoC re-run:

Bad behavior gone; fix validated.

Harness notes / honest caveats

• Two earlier harness iterations produced null/false results (a DECLARE_MODULE misuse panicking module_register's strcmp; same-CPU pinning + spin handshake starving the reader). Both were harness bugs, diagnosed from the DDB backtrace and fixed; the final harness (this pack) pins writer=cpu0/reader=cpu2 and tsleep-polls handshakes.
• Stage A's exact-poison reclaim is probabilistic (~1/5 with 1 block, ~4/5 with 8-spray); stage B's is deterministic (3/3 in every run). UAF detection (contents changed under the reader) was 100% in runs 2 and 3.

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.