DF-0053 — PoC (master DEV re-verification)

Status: REPRODUCED on DragonFly v6.5.0.1712.g89e6a-DEVELOPMENT (built 2026-06-29, x86_64, X86_64_GENERIC config with INVARIANTS).

The prior not_reproduced verdict was an OID-name typo: the sysctl is jail.list (top-level, SYSCTL_OID(_jail, OID_AUTO, list, ...) at sys/kern/kern_jail.c:757), NOT kern.jail.list. With the correct OID the bug fires immediately.

The bug

sysctl_jail_list (sys/kern/kern_jail.c:661) sizes its output buffer as count * 1024 bytes (one 1024-byte budget per jail) but the per-jail formatted output ("%d %s %s" = pr_id + pr_host + fullpath, kern_jail.c:704-706) can reach ~1282 bytes (MAXHOSTNAMELEN=256 + cache_fullpath MAXPATHLEN=1024 + small jid). ksnprintf returns the would-be (untruncated) length (sys/kern/subr_prf.c:549 retval++ is unconditional; snprintf_func at :494 only writes while remain>=2), so jlsused += count (kern_jail.c:710) makes jlsused exceed jlssize. The IP loop's bounds check (jlssize - jlsused) (:733) then underflows (both are unsigned int, :671) to ~UINT_MAX → check (huge < strlen(oip)+1) is FALSE → ksnprintf(jls+jlsused, ~UINT_MAX, " %s", oip) at :737 writes the IP string at jls+jlsused past the buffer end → kernel heap OOB write. The final SYSCTL_OUT(req, jls, jlsused) at :749 copies jlsused bytes from the allocation to userspace → kernel heap OOB read (info leak of adjacent slab slack).

Reachability

The handler's only check is jailed(td->td_ucred) (:679); any unprivileged unjailed user can read the sysctl. Precondition: at least one jail whose host + fullpath formatted length exceeds ~1024 bytes (a deep chroot path created by root — realistic on jail/container hosts).

Reproduce

# Phase 1 (root): create the long-path jail
ssh dfbsd   # or: vm.sh run_root 'sh /path/to/setup_jail_v3.sh 60 4'
sh findings/poc/DF-0053/setup_jail_v3.sh 60 4

# Phase 2 (any user): trigger the bug
ssh dfbsd-maxx
cd findings/poc/DF-0053 && cc -O2 -o jail_list_trigger jail_list_trigger.c
./jail_list_trigger

Or use the convenience scripts:

./build.sh                       # cc -O2 -o jail_list_trigger jail_list_trigger.c
sudo sh ./run.sh setup           # root: provision the jail
su maxx -c ./run.sh              # maxx: trigger (or any unprivileged user)

Expected output (bug present)

[+] BUG DF-0053 CONFIRMED:
    kernel returned 1261 bytes
    jlssize (count*1024)         = 1024
    kmalloc bucket (alloc)       = 1152
    OOB READ vs jlssize          = 237 bytes
    OOB READ vs actual alloc end = 109 bytes (info leak of adjacent slab slack)
    OOB WRITE (IPs written past alloc end during IP loop) also occurred in kernel heap
    non-zero bytes in OOB-vs-alloc region: 36 (our written IPs + any stale slab data)

The kernel returned 1261 bytes from a buffer that is logically 1024 bytes (jlssize) and physically 1152 bytes (the slab bucket zoneindex() rounds kmalloc(1025) up to — sys/kern/kern_slaballoc.c:663 (1025+127) & ~127 = 1152). The trailing 110 bytes (offsets 1152..1262) were never part of the allocation — they are adjacent slab slack that the kernel both wrote into (the IP strings, OOB write) and copied out to userspace (OOB read / info leak).

Expected output (FIXED kernel — verified on #1 single-fix build)

[+] FIX CONFIRMED (DF-0053): kernel returned ERANGE (refused to format oversized jail.list line)
    -> no OOB write into adjacent slab, no OOB read to userspace.  Bug closed.

The fix (fix.diff) clamps jlsused <= jlssize at every cursor advance (kern_jail.c:710 and :741) and adds an underflow-proof short-circuit to the IP-loop bounds check (:733/:738). When the pathological line would exceed the buffer, the IP-loop guard trips error = ERANGE; goto end before the IP-loop ksnprintf can write past the buffer (no OOB write) and before SYSCTL_OUT runs (no OOB read). Normal short-path jails list unchanged (regression-checked on #1).

Impact

• OOB write into adjacent kernel heap slab memory (the IP strings, ~36 bytes with 4 IPs; grows linearly with the jail's IP count up to jail(8)'s IP-parse limit). Content is the jail's formatted IP/hostname/path — set by root at jail(2) time, not directly attacker-shaped, but the write POSITION and LENGTH are attacker-observable and the trigger is freely repeatable. With heap grooming this is a memory-corruption primitive that could be converted to local privilege escalation (corrupt an adjacent struct file/ucred/ function-pointer victim in the 1152-byte bucket).
• OOB read / info leak of up to ~110 bytes of adjacent slab slack to userspace per read. In this run the leaked bytes are zero (the adjacent chunk was freshly M_ZERO-allocated) plus our own written IPs; with heap grooming (spray the 1152-byte bucket with pointer-bearing objects before triggering), this leaks kernel pointers / stale slab data.
• Local DoS is straightforward (the OOB write corrupts adjacent slab; repeated triggers can panic a less-fortunate kernel layout — not observed in 50x rapid repeats on this build, but the corruption is real).

High severity: confirmed memory corruption + info leak, reachable by any unprivileged local user via a sysctl read, with a realistic precondition (a long-chroot-path jail).

Escalation-chain analysis (Phase 6, this session)

The primitive was pushed toward uid=0. The OOB write is the jail's formatted IP strings, so the attacker-controlled content is restricted to the IP-string byte-set {0x20, 0x2e, 0x30-0x39} (IPv4), plus {0x3a, 0x61-0x66} (IPv6), plus one trailing 0x00. The offset of the write within the adjacent slab chunk is fully tunable via the chroot path depth; the length is tunable via the jail IP count (the kernel has no IP limit at kern_jail.c:308; jail(8) userland has its own ~24-IP realloc heap bug at usr.sbin/jail/jail.c:110, so mkjail.c calls jail(2) directly to create a 100-IP jail).

Bucket & victim

The OOB stays inside the 1152-byte slab zone (kmalloc(1025) -> 1152, zoneindex align 128). Slab pages are single-zone, so the adjacent chunk is always a 1152-byte object. Struct-size scan: the only live zone-40 objects are struct pmap (1088) and kinfo_proc (1048, output-only). All classic credential/funcptr victims — ucred(256)/file(128)/socket(696)/proc(1208)/ filedesc(848) — are in other zones and are structurally unreachable.

struct pmap (sys/platform/pc64/include/pmap.h:267) ends with a block of function pointers (copyinstr@968, copyin@976, copyout@984, fubyte, subyte, fuword32@1008, fuword64, suword*, swapu32@1040, swapu64, fuwordadd*), initialized to std_copyin (0xffffffff80bcaf50) at pmap.c:2276. They are the live per-syscall dispatch path: the global copyin() is curthread->td_proc->p_vmspace->vm_pmap.copyin(...) (uwrapper.c). Corrupting a process's pmap->copyin hijacks its next copyin.

Reach — PROVEN empirically (offset/content control)

With a 100-IP jail (host=255, fullpath=954 -> jlsused_first=1212), the IP-loop OOB write covers adjacent-chunk offsets [73 .. 1065], fully covering the pmap funcptr block (968-1072):

$ ./jail_list_oob_analyze
kernel returned: 2217 bytes (jlssize=1024, alloc bucket=1152)
OOB WRITE region in adjacent chunk: offsets [73 .. 1065] (992 bytes)
  pmap->copyin   off=976   COVERED (8/8 bytes overwritten)
  pmap->fuword32 off=1008  COVERED
  pmap->swapu32  off=1040  COVERED

Why uid=0 is blocked (verified, path:line + symbol evidence)

1. Redirect to userspace shellcode (SMEP OFF would allow it) — BLOCKED. A pre-init funcptr holds 0xffffffff80bcaf50 (high bytes 0xffffff ff 80). An 8-byte IP overwrite is >= 0x2020…20 with bits 48-63 nonzero, bit 47 zero -> non-canonical -> #GP on call. A partial overwrite leaves high bytes 0xff (kernel). Only one 0x00 (trailing null) per write can zero one byte — insufficient for a canonical userspace pointer. SMAP/SMEP/KASLR are all OFF; the obstacle is purely that the IP byte-set cannot form a userspace address against a pre-init kernel pointer.
2. Redirect to a kernel privilege gadget (3-byte partial overwrite) — BLOCKED. 3-byte overwrite (byte3 stays 0x80) reaches [0xffffffff80202020 .. 0xffffffff80666666]. Full symbol scan: 62 functions at IP-formable addresses, all driver/module/linker/wifi; no credential/uid/privesc function. DragonFly has no commit_creds/prepare_kernel_cred; change_euid/cratom_proc/ crfree/sys_setuid all have non-IP-formable low bytes.
3. Corrupt a ucred/proc/file pointer — STRUCTURALLY IMPOSSIBLE (different slab zones; same-zone-only adjacency).
4. pmap page-table forge — BLOCKED (needs a user-page physical address; unavailable to unprivileged users).

Result: the primitive corrupts a real live callable function-pointer victim (reach + dispatch proven), but cannot form any privilege target address from the IP byte-set, and there is no single-call DragonFly escalation to redirect to. Realistic ceiling: local DoS + ~1 KB info leak of adjacent zone-40 slab per read. uid=0 not achievable from this primitive on this configuration.

Grooming attempts

df0053_groom.c / df0053_groom2.c fork 80-200 zone-40 pmaps and trigger jail.list (punching holes between live pmaps). In-session runs hit inert (free) adjacent chunks — no live pmap was forced adjacent. Cause: per-CPU LIFO free lists (jls is freed back to the head each sysctl_jail_list call, so repeated triggers re-take the same chunk) + no cpuset(1) on this guest to pin forker/children/sysctl to one CPU. A deterministic adjacent-pmap layout would need CPU-pinned single-CPU grooming + a zone-40 stuffer alloc between triggers. This is a grooming-reliability limit, not a property of the primitive.

Reproduce (escalation analysis)

# root: 100-IP long-path jail (needs mkjail; jail(8) caps ~24 IPs)
sudo sh ./run.sh setup100           # builds path + sleeper + mkjail, creates 100-IP jail
# unprivileged: prove the OOB reaches the pmap funcptr block
su maxx -c "./run.sh analyze"       # -> "OOB WRITE region [73..1065]; pmap->copyin COVERED"
# unprivileged: attempt heap-feng-shui (in-session: hits inert chunks)
su maxx -c "./run.sh groom"

DF-0053 — Verdict (escalation-pass 2 re-verification)

Verdict: REPRODUCED (OOB write + OOB read primitive, confirmed). Escalation to uid=0 is BLOCKED by a thoroughly-verified structural dead-end — TWO avenues exhaustively explored and both blocked with hard evidence. FIX VALIDATED.

1. Primitive (confirmed on master DEV #0, this session)

Unprivileged sysctl jail.list triggers an OOB write + OOB read in the zone-40 (1152-byte) slab. Root cause: ksnprintf returns the would-be length (not bytes written); jlsused += count can exceed jlssize, causing the unsigned jlssize - jlsused to underflow to ~UINT_MAX, bypassing the IP-loop bounds check at kern_jail.c:733. Result: ksnprintf at :737 writes IP strings past the allocation end, and SYSCTL_OUT at :749 copies jlsused bytes from the 1152-byte alloc to userspace.

Confirmed as maxx (uid 1001) with a 100-IP jail:

kernel returned: 2218 bytes (jlssize=1024, alloc bucket=1152)
OOB WRITE region in adjacent chunk: offsets [73..1065] (992 bytes)
OOB READ (info leak): 1066 bytes past alloc end

2. Escalation analysis — Avenue 1 (exhaustive gadget hunt)

2a. Achievable partial-overwrite addresses

The OOB content is IP-string bytes {0x20,0x2e,0x30-0x39,0x3a,0x61-0x66} plus printable ASCII header-path bytes {0x20-0x7e} from multi-jail configurations, plus exactly ONE trailing null (\0 from the final ksnprintf).

For each funcptr in struct pmap (offsets 968-1072), the null can zero one byte, yielding these canonical kernel-text addresses:

• k=0 (null at byte 0): 7 unique fixed addresses (one per funcptr, all ~0x50-0xB0 bytes before the corresponding std_* function). Each is in the done_* tail or mid-instruction of an adjacent function.
• k=1 (null at byte 1): 0xffffffff80bc0020..007e (95 addresses, all inside Xmsi_intr115's register-zeroing prologue — xor rax,rax; mov rbx,rax; ...; mov r15,rax; nop; movq $0,...(%rsp) × 4; cld; mov global,%rax; call *%rax).
• k=2 (null at byte 2): 0xffffffff8000XXYY — NOT MAPPED (confirmed by ELF section scan: no loaded section covers this range).
• k=3+ (null at byte 3+): 0xFFFFFFFF00XXXXXX — PML4 entry 510, canonical but no mapped/executable section. Dead.
• Full overwrite (all 8 bytes formable): bits 47-63 not uniform → non-canonical → #GP on indirect call → panic.

Total: 102 reachable addresses in kernel text.

2b. Gadget scan (definitive — ALL 102 addresses × 15 patterns)

Scanned the kernel .text section (10,012,433 bytes, VA 0xffffffff802aabb0..0xffffffff80c372c1) for every useful gadget pattern:

Zero stack pivots, zero control-flow redirects, at any reachable address.

Two bare ret (0xc3) exist at 0xffffffff80bc0023 and 0xffffffff80bc003e (k=1), but they return the nonzero funcptr value in RAX (set by the retpoline dispatch) — the caller treats nonzero as an error. Not a "return 0" success.

2c. The xchg gadget — correct primitive but unreachable callers

The ONE interesting gadget is xchg rax,[rdi] at 0xffffffff80bcb300 (fuwordadd64/fuword32/fuword64 k=0 target, inside std_swapu64):

ffffffff80bcb300:  39 c7              cmp  edi, eax        ; 32-bit compare!
ffffffff80bcb302:  0f 87 78 01 00 00  ja   fusufault
ffffffff80bcb308:  48 89 f0           mov  rax, rsi        ; rax = arg2 (controlled)
ffffffff80bcb30b:  48 87 07           xchg rax, (%rdi)     ; atomic swap!

Critical insight: the entry at 0xffffffff80bcb300 skips the REX.W prefix (0x48) of the original cmp rax,rdi (64-bit bounds check). The misaligned decode produces cmp edi,eax (32-bit) where eax = 0x80bcb300. This bypasses the address validation: any address whose low32 ≤ 0x80bcb300 passes, including recursive page-table mapping addresses (PML4PML4I=256, addr_PML4map = 0xFFFF800420100000, low32 = 0x20100000).

Via the recursive mapping, this gadget gives arbitrary atomic write to any page-table entry (PML4/PDPT/PD/PT) — potentially allowing a PTE-swap attack to map a kernel physical page at a user virtual address, then modify kernel credentials.

BUT — the gadget is unreachable from userspace:

The xchg gadget is at the fuwordadd64 k=0 target. The only kernel function that calls pmap->fuwordadd64 with TWO controlled arguments (rdi=base, rsi=val) is fuwordadd64(). Grep of ALL kernel C code shows fuwordadd64 has ZERO callers outside the vkernel64 platform. No syscall or kernel code path invokes it.

The funcptrs that DO have userspace callers cannot reach this gadget: - copyin/copyout/copyinstr (k=0 = done_copyout tail, returns error) - fuword32/64 (called from exec argv scan, but only rdi=ptr is an argument; rsi is uncontrolled leftover) - fuwordadd32 (called from umtx_sleep, but k=0 target 0xffffffff80bcb200 decodes as add %al,[rip+0] → writes to kernel text → fault) - swapu32/swapu64 (zero callers outside vkernel) - suword32/subyte (k=0 target is the original function entry → no-op)

This is a genuine structural dead-end: the right gadget exists but no userspace-accessible code path can invoke it with controlled arguments.

2d. The 3 mov rsp,rdi gadgets — not formable

Three mov rsp,rdi instructions exist in .text (48 89 fc): - 0xffffffff80661554 (low bytes 0x54 — not formable, not followed by ret) - 0xffffffff808469e4 (low bytes 0xe4 — not formable) - 0xffffffff8084811e (low bytes 0x1e — not formable)

None are at addresses reachable by any partial-overwrite depth, and none are followed by ret. Even if reachable, they'd be incomplete pivots.

3. Escalation analysis — Avenue 2 (single-CPU groomer)

3a. The privilege blocker

DragonFly's usched_set syscall (481) requires SYSCAP_NOSCHED_CPUSET for both USCHED_SET_CPU (cmd=1) and USCHED_SET_CPUMASK (cmd=6):

case USCHED_SET_CPU:
    if ((error = caps_priv_check_self(SYSCAP_NOSCHED_CPUSET)) != 0)
        break;

An unprivileged user cannot pin to a specific CPU. Verified empirically: usched_set(getpid(), 1, &0, 4) as maxx returns EPERM.

3b. Why this blocks the groomer

DragonFly's slab allocator uses per-CPU LIFO free-lists. The jls buffer is kfree'd back to the head of the current CPU's zone-40 free-list at the end of each sysctl_jail_list call. Without CPU pinning, the sysctl thread, the forker, and the forked children run on different CPUs — their zone-40 free-lists don't coincide, so the jls allocation never lands adjacent to a specific live pmap.

A groomer was written (df0053_panic.c) that forks 200 children and triggers the sysctl 100 times. It ran without triggering a panic — the adjacent chunk was consistently a freed/zeroed slab object, not a live pmap.

This is a reliability limitation, not a primitive limitation. On a busy system with many zone-40 allocations, the adjacent chunk WILL sometimes be a live pmap, and the corrupted funcptr block (non-canonical address from IP-byte overwrite) will cause a kernel panic on the owning process's next copyin/copyout. But reliable, on-demand panic is not achievable without CPU pinning.

4. Why uid=0 is structurally unreachable from this primitive

Three independent constraints, each sufficient alone to block uid=0:

1. Content byte-set: the OOB write bytes are IP-string/printable-ASCII chars plus ONE trailing null. Cannot form canonical userspace addresses (requires 2+ high-byte zeros) or 0x80 (needed for byte 3 of kernel-text pointers). Only k=0/k=1 partial overwrites give canonical kernel-text addresses.

2. Gadget availability: the 102 reachable addresses contain ZERO useful gadgets (no stack pivot, no control-flow redirect). The one xchg gadget is unreachable from userspace (fuwordadd64 has no callers).

3. Zone constraint: the OOB stays within zone-40 (1152-byte slab). struct ucred (256 B), struct proc (1280 B), struct file (128 B) are all in other zones. Slab pages are single-zone, so the OOB can NEVER reach credential/proc/file structures.

Realistic impact ceiling: local DoS (kernel heap corruption; probabilistic panic when adjacent chunk is a live pmap) + info leak (~1 KB of adjacent zone-40 slab per read, kernel pointers if a live pmap is adjacent). Confirmed memory corruption + info leak, unprivileged trigger. Not promoted to uid=0.

5. PoC artifacts in this folder

6. Fix validation

fix.diff restores the invariant jlsused <= jlssize at every cursor advance and makes the IP-loop bounds check underflow-proof (jlsused >= jlssize ||). On the fixed kernel (#1), sysctl jail.list returns ERANGE instead of the OOB data — no OOB write, no OOB read. Validated by prior session; re-confirmed in this session.