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 1262 bytes
    jlssize (count*1024)         = 1024
    kmalloc bucket (alloc)       = 1152
    OOB READ vs jlssize          = 238 bytes
    OOB READ vs actual alloc end = 110 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: 37 (our written IPs + any stale slab data)

The kernel returned 1262 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).

A fixed kernel would clamp jlsused to jlssize whenever truncation occurs, and would never return more bytes than jlssize.

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).

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

Verdict: REPRODUCED on DragonFly v6.5.0.1712.g89e6a-DEVELOPMENT (X86_64_GENERIC, INVARIANTS, built 2026-06-29).

Why the prior run said "not_reproduced"

The prior test (on 6.4.2-RELEASE) reported "KEY VERSION DIFF: the vulnerable sysctl is named jail.list on 6.4.2 (kern.jail.list is 'unknown o...')". That was mis-read as a version difference. It is not — it is an OID-name typo in the original finding markdown. The OID has always been the top-level jail.list (declared SYSCTL_OID(_jail, OID_AUTO, list, ...) at sys/kern/kern_jail.c:757); there is no kern.jail.list. The same OID exists on both 6.4.2 and 6.5-DEVELOPMENT (master DEV). With the correct name, the bug fires immediately on master DEV.

Confirmed on master DEV

$ sysctl -aN | grep -iE '^jail\.'
jail.jailed
jail.list            <-- the vulnerable OID
jail.defaults.vfs_mount_fusefs
...
$ sysctl -d jail.list
jail.list: List of active jails

sysctlnametomib("jail.list") resolves to OID {258, 257} (258 = jail subtree). Reading it as the unprivileged user maxx (uid 1001, not in wheel):

[*] MIB for jail.list: 258 257
[*] kernel reports jail.list length = 1262 bytes
[*] sysctl read returned 1262 bytes
[*] 1 jail lines -> jlssize = 1024 bytes (kmalloc(1024+1) -> bucket 1152)
[+] BUG DF-0053 CONFIRMED:
    kernel returned 1262 bytes
    jlssize (count*1024)         = 1024
    kmalloc bucket (alloc)       = 1152
    OOB READ vs jlssize          = 238 bytes
    OOB READ vs actual alloc end = 110 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: 37 (our written IPs + any stale slab data)

Reproduced 3× (byte-identical output — see run.3x.log). Hammered 50× back-to-back: no panic, but every read does a fresh OOB write into adjacent slab memory.

Mechanism (cited path:line)

Setup: a single jail with a deep chroot path (60 levels × lllllllllllllll = path_len 967), MAXHOSTNAMELEN-1 = 255-char hostname, and 4 IPv4 IPs. Created as root via jail(2) (sys/kern/kern_jail.c:255 sys_jail, gated by caps_priv_check_self(SYSCAP_NOJAIL_CREATE) at :265 — the only privilege boundary; reading jail.list has no such gate).

Trigger: any unprivileged user reads sysctl jail.list → handler sysctl_jail_list (sys/kern/kern_jail.c:661):

1. Types (:671): unsigned int jlssize, jlsused; — both 32-bit unsigned.
2. Size + alloc (:688-689): jlssize = (count * 1024); → 1024 for 1 jail. jls = kmalloc(jlssize + 1, M_TEMP, M_WAITOK | M_ZERO); → requests 1025 bytes. zoneindex() (sys/kern/kern_slaballoc.c:663) rounds to bucket (1025+127) & ~127 = 1152. Physical allocation is 1152 bytes.
3. First ksnprintf (:704): count = ksnprintf(jls + jlsused, (jlssize - jlsused), "%d %s %s", pr->pr_id, pr->pr_host, fullpath); - size arg = 1024 - 0 = 1024. - format expands to "11 " + 255*'h' + " " + 967-char path = 1226 bytes. - snprintf_func (sys/kern/subr_prf.c:494) writes only while remain >= 2 → writes 1023 chars + NUL into jls[0..1023] (truncated, in-bounds). - But PCHAR (subr_prf.c:549) does retval++ unconditionally — the return value is the would-be length 1226, not the truncated length.
4. jlsused += count (:710): jlsused = 0 + 1226 = 1226. Now jlsused > jlssize (1226 > 1024).
5. IP loop bounds check (:733): if ((jlssize - jlsused) < (strlen(oip) + 1)) → (1024 - 1226) in unsigned int arithmetic = 0xFFFFFB6E (~4294966062). 4294966062 < 9 is FALSE → does NOT trip ERANGE.
6. IP loop ksnprintf (:737): count = ksnprintf(jls + jlsused, (jlssize - jlsused), " %s", oip); - writes at jls + 1226 with size ~UINT_MAX → no truncation. - jls + 1226 is 74 bytes past the 1152-byte allocation end → OOB WRITE of " 10.0.0.1" (9 bytes) into adjacent slab memory. - repeats for each IP → OOB writes at jls+1226, +1235, +1244, +1253 (4 IPs). jlsused grows to 1262.
7. SYSCTL_OUT (:749): error = SYSCTL_OUT(req, jls, jlsused); - copies jlsused = 1262 bytes from the 1152-byte allocation to userspace. - bytes [1152..1262] (110 bytes) are past the allocation end → OOB READ / info leak of adjacent slab slack.

The leaked bytes observed: - Offsets [1152..1225]: zero (slab slack, freshly zeroed by M_ZERO). - Offsets [1226..1261]: the IPs we wrote (" 10.0.0.4 10.0.0.3 ..." in SLIST-reverse order).

Exploit chain (memory-corruption primitive)

Bucket: the 1152-byte slab zone (zoneindex of size 1025; align 128). Victim objects: any kmalloc(N) whose N ∈ (1024, 1152] lands in the same zone. Candidate victim objects containing attacker-interesting fields in this size range should be grepped in sys/ (function-pointer ops vectors, struct ucred */struct file */struct proc * pointers, refcounts, uids). Grooming: spray the 1152-byte bucket (sockets, pipes, file opens, mmaps) to fill partial slabs; punch a hole adjacent to the next jail.list buffer; trigger the sysctl → OOB write the IP strings into the victim object. Conversion: depends on the victim — overwrite a function pointer → pivot; overwrite a ucred * → forge; overwrite a refcount → UAF → re-claim → write. Content control: the OOB write content is the jail's formatted IP strings, set by root at jail(2) time — not directly attacker-shaped in the default unprivileged-attacker model. A semi-privileged attacker (one who can create jails) fully controls it. The OOB write POSITION/LENGTH is attacker-observable (via jls) and the trigger is freely repeatable, so the corruption primitive is deterministic even with root-set content (corrupt → observe via leak → re-corrupt).

Where this verification stopped: confirmed the OOB write + OOB read primitive end-to-end on master DEV. Did not develop a full heap-grooming + victim-corruption → uid=0 chain (the OOB write content is not attacker-controlled in the strict unprivileged model, so a uid0 chain would require either (a) root cooperation to set IP strings to gadget-shaped bytes, or (b) finding a victim object in the 1152-byte bucket whose corruption with printable-IP bytes yields a usable primitive). The realistic impact ceiling on the strict model is local DoS + info leak of adjacent slab (with grooming for pointer leakage); with jail-creation capability it escalates to full memory corruption → likely privesc. 50× repeated triggers did not panic this build (the adjacent slab chunks were benign), but the corruption is real and a less-fortunate heap layout would crash.

PoC changes vs the original

• OID name: original PoC/finding used kern.jail.list; corrected to the actual top-level jail.list (SYSCTL_OID(_jail, OID_AUTO, list, ...) at kern_jail.c:757). This was the sole blocker for the prior not_reproduced verdict — not a version difference.
• Setup script: rewrote as setup_jail_v3.sh — fully self-contained, builds the deep path one mkdir per level (because mkdir -p silently truncates long paths on DragonFly), copies a static sleeper binary into the chroot as /s, launches jail(8) backgrounded so the prison survives ssh disconnect (the sleeper keeps it alive).
• Trigger: rewrote jail_list_trigger.c to (a) use sysctlnametomib() for the OID, (b) compare the returned byte count against both jlssize (count*1024) AND the actual slab bucket (1152), and (c) hexdump the OOB tail so the leaked bytes are visible.
• Did NOT need to change: the underlying bug claim, the cited path:lines, or the recommended fix — all are accurate against the audited master DEV tree.

Decisive evidence

• run.log — single decisive run; [+] BUG DF-0053 CONFIRMED with the byte accounting.
• run.3x.log — three back-to-back runs, byte-identical (deterministic because the adjacent slab was M_ZERO-zeroed; the OOB read LENGTH is proven regardless of content variance).
• leak_sample.txt — the OOB tail bytes.
• env.txt — uname -a, cc --version, sysctl jail.list, jls.
• dmesg.txt — full guest dmesg (no slab-corruption warnings on this build — INVARIANTS in kern_slaballoc.c only catches use-after-free via the weirdary pattern at :1566-1572, not real-time OOB-write detection).
• No panic (panic.txt not applicable — guest stayed up across 50+ triggers).

DF-0053 — Fix notes (post-verification, authored by df-bsd-pocrunner)

fix.diff is a standalone, git apply-able unified diff against the read-only sys/ tree (never applied here). Verified to apply cleanly via both git apply --check (rc=0) and patch --dry-run -p1 against sys/kern/kern_jail.c at repo HEAD.

Root cause (confirmed by verification)

sysctl_jail_list() (sys/kern/kern_jail.c:661) sizes its buffer as jlssize = count * 1024 (:688) but advances the write cursor jlsused (:671, unsigned int) by the would-be length that ksnprintf returns (:710 after the per-jail ksnprintf at :704, and :741 after each IP ksnprintf at :737). That length can exceed the per-jail budget, so jlsused can exceed jlssize. Once it does, every unsigned (jlssize - jlsused) underflows to ~UINT_MAX: the IP-loop bounds check at :733 (huge < strlen(oip)+1 ⇒ FALSE) stops firing, ksnprintf at :737 gets a ~UINT_MAX size and writes past the allocation end (OOB write), and the final SYSCTL_OUT(req, jls, jlsused) at :749 copies jlsused > jlssize bytes out (OOB read / info leak).

What the fix does

Restores and enforces the invariant jlsused <= jlssize at every cursor advance, and makes the IP-loop bounds check underflow-proof:

1. :710 (after the per-jail ksnprintf) — clamp: if the would-be length is >= the remaining space, set jlsused = jlssize instead of advancing.
2. :733 (IP-loop bounds check) — add an explicit jlsused >= jlssize || short-circuit so the unsigned subtraction can never underflow and bypass the check (defense-in-depth).
3. :741 (after each IP ksnprintf) — same clamp as :710.

With the invariant held, (jlssize - jlsused) is always a small, valid non-negative value, so the ksnprintf size args (:704, :737) and the SYSCTL_OUT length (:749) can never overflow. The terminator still lands in the kmalloc(jlssize + 1, ...) slack byte. When the buffer fills, the IP-loop guard trips ERANGE and goto end returns cleanly (no OOB write, no OOB read).

Why this supersedes the finding markdown's ## Recommended fix

The finding proposed only two hunks: the clamp at :710 and the guard at :733. That pair is incomplete for the multi-prison case: if prison N's last IP ksnprintf returns a would-be length that over-advances jlsused past jlssize at :741, the IP-loop guard at :733 never re-trips (there is no next IP), LIST_FOREACH advances to prison N+1, and the per-jail ksnprintf at :704 receives (jlssize - jlsused) which underflows and overflows the buffer — re-opening the exact defect. Adding the third clamp at :741 (hunk 3) is what actually restores the invariant for all iteration orders and closes the bug fully. The clamp expression, guard form, and :710/:733 hunks otherwise match the finding's proposal.

Verification of the diff itself

$ git apply --check findings/poc/DF-0053/fix.diff     # rc=0
$ patch --dry-run -p1 < findings/poc/DF-0053/fix.diff  # "checking file sys/kern/kern_jail.c", no rejects

(Not applied to sys/ — the audit tree is read-only. Behavioral confirmation that clamping jlsused to jlssize eliminates the overflow is implied by the trigger PoC: a fixed kernel would return at most jlssize bytes and the [+] BUG DF-0053 CONFIRMED markers would not fire.)