DF-3156 — dangling RRIP NM-CONTINUE chain makes the defname fallback write the ISO name out of bounds (kernel stack in lookup, kernel heap in readdir) — verified to unprivileged uid=0

What (root cause)

cd9660_rrip_altname() (sys/vfs/isofs/cd9660/cd9660_rrip.c:226-284) advances ana->outbuf by every NM fragment (:276-277) and only rewinds it on the > ana->maxlen rejection (:271). A fragment whose FLAGS byte has CONTINUE set never completes the name — it returns 0 without setting the ISO_SUSP_ALTNAME result bit (:279-283).

If the SUSP walk then ends without a terminating NM fragment — trivially arranged: the last field of the walk is a CONTINUE-flagged NM in a CE continuation area — cd9660_rrip_loop()'s default-value fallback (:581-584) invokes cd9660_rrip_defname(), which runs

isofntrans(isodir->name, isonum_711(isodir->name_len),
       ana->outbuf, ana->outlen, ...);          /* rrip.c:289-292 */

at the stale advanced pointer base + N where N is the accumulated fragment length (up to 255, reached via CE continuations), writing the record's translated ISO name (up to ~183 bytes, attacker-chosen content, copied verbatim at joliet_level 0 / original=1) — up to 183 bytes past the end of a 255-byte output buffer:

• cd9660_lookup() (cd9660_lookup.c:109 char altname[NAME_MAX]) — kernel stack; OOB bytes 22..29 = saved RBP, 30..37 = saved RIP (measured: frame pointer = 0x444342415a595857 = our cycling A..Z pattern, Stopped at cd9660_lookup+0x461: ret).
• cd9660_readdir() (cd9660_vnops.c:542, buffer = idp->current.de.d_name inside the kmalloc'd struct isoreaddir) — kernel heap; the write smashes the isoreaddir tail: curroff, uio pointer, uio_off, eofflag, cookies, ncookies (measured: Fatal trap 9 ... iso_uiodir+0x25: cmpq %rax,0x18(%r8) — the corrupted idp->uio dereferenced).

All fragment lengths are individually valid (>= 5) and each passes the > maxlen check — this is not the DF-3146 negative-wlen underflow and not the DF-0878 entry-length OOB-read family; the defect is the missing output-buffer reset on the default-name fallback path.

Verified impact (guest 6.5-DEVELOPMENT #0, stock INVARIANTS kernel)

1. Unprivileged kernel memory corruption — getdents/ls (heap) or any stat/path resolution (stack) under the mount, as any user.
2. Full unprivileged → uid=0 chain (exploit.c + df3156_exploit.iso): * the heap variant corrupts idp->uio to point at a **fake struct uio
   • struct iovec in the (unprivileged) process address space**;
   • iso_uiodir() → uiomove(dirent, 152, fake_uio) with uio_segflg=UIO_SYSSPACE bcopys the dirent (16-byte header + the NM-chain bytes, all attacker data) to the fake iov_base — an arbitrary kernel write with no SMAP to stop it;
   • the write targets &sysent[71]-16, hijacking the obsolete syscall 71 (old mmap) sy_call to a ring0 stub at a fixed user address (no SMEP), while restoring every live sysent entry it touches (munmap/mprotect/madvise/sbrk-neighbors) with their original values;
   • syscall(71) executes the stub in ring0: %gs:0 → gd_curthread(+8) → td_proc(+168) → p_ucred(+16) then cr_uid=cr_ruid=cr_svuid=0, cr_ngroups=1, cr_caps=~0;
   • the syscall returns through the intact syscall path; the process is now root — uid after: 0 euid: 0, reads the root-only /root/df3156_rootproof (mode 0400). Guest stays up.
3. The stack variant gives direct saved-RIP/RBP control (panic evidence in panic_lstat.txt) — an alternative escalation route not needed for the demonstrated chain.

Threat model: crafted RRIP ISO mounted by root (same setup as the DF-0878/0879/DF-3124/DF-3146 crafted-media family); after the mount ANY unprivileged user with read access triggers via getdents/stat/ls.

Reproduce

Host: python3 craft_dangle.py pat184 out.iso (pattern trigger), python3 craft_exploit.py df3156_exploit.iso (full chain). Stage the pack into the guest and:

cc -O -o /tmp/exploit /root/exploit.c ; cc -O -o /tmp/trigger /root/trigger.c
echo "SECRET-ROOT-ONLY-DF3156-$(date +%s)" > /root/df3156_rootproof
chmod 400 /root/df3156_rootproof ; mkdir -p /mnt/df3156
vnconfig -c -S 2048 /dev/vn0 /root/df3156_exploit.iso
mount_cd9660 -o ro /dev/vn0 /mnt/df3156
su -m nobody -c "/tmp/exploit /mnt/df3156"     # -> uid after: 0 + secret
# stack-smash proof (panics the box):
vnconfig -u /dev/vn0 ; vnconfig -c -S 2048 /dev/vn0 /root/df3156_pat183.iso
mount_cd9660 -o ro /dev/vn0 /mnt/df3156
su -m nobody -c "/tmp/trigger lstat /mnt/df3156"

Fix

fix.diff — rewind ana->outbuf/*ana->outlen to the buffer base at the top of cd9660_rrip_defname() (no-op when no NM fragment was seen). Validated on a rebuilt kernel (#1): both triggers become clean fallback names (name='A', pattern name at base), no panic, no uid0 (fix_run_exploit.log).

DF-3156 VERDICT — reproduced, uid0

Bottom line

reproduced / uid0_privesc / certain. A crafted Rock Ridge ISO makes cd9660_rrip_defname() write up to 183 fully attacker-controlled bytes at output_buffer + 255 — past a 255-byte kernel-stack array in cd9660_lookup() and past the dirent name area of the kmalloc'd struct isoreaddir in cd9660_readdir(). The heap variant was turned into an arbitrary kernel write (fake struct uio), then into a hijack of sysent[71].sy_call, then into ring0 execution of a userland stub that zeroes the calling process's credentials — nobody ends with uid=0 euid=0 and reads a mode-0400 root file, on the stock INVARIANTS kernel #0, from a fresh vm.sh reset. The two-line fix.diff was built as kernel #1 and re-tested: both triggers degrade to clean fallback names, no panic, no escalation.

How it works (path:line)

1. Dangling chain. cd9660_rrip_altname (sys/vfs/isofs/cd9660/cd9660_rrip.c:226-284) bcopy()s every NM fragment and advances ana->outbuf (:276-277). A fragment with FLAGS&ISO_SUSP_CFLAG_CONTINUE (0x01) returns 0 without setting the ISO_SUSP_ALTNAME result bit (:279-283) — the name is "still coming". The craft places such an NM as the final field of a CE continuation area (craft_exploit.py): after it the walk simply runs out of fields (pend reached, iso_ce_len == 0 → loop breaks at :544-545).
2. Fallback at the stale pointer. Because result lacks ISO_SUSP_ALTNAME, the default-value loop (:581-584) calls cd9660_rrip_defname, which isofntrans()es the record's ISO name at ana->outbuf = base + 255 (:289-292) — OOB. Budget arithmetic: reclen(255) = 33 + name_len + NM1(10) + CE(28) → name_len ≤ 183; chain length N = 5 + 250 = 255 (the *outlen > maxlen=NAME_MAX check caps N at 255 — both fragments individually legal).
3. Stack sink. cd9660_lookup (cd9660_lookup.c:109 char altname[NAME_MAX]) — 183 controlled bytes from base+255; measured saved RBP at OOB+22, saved RIP at OOB+30: frame pointer = 0x444342415a595857, Stopped at cd9660_lookup+0x461: ret (panic_lstat.txt) — direct return-address control.
4. Heap sink → arbitrary write. In cd9660_readdir (cd9660_vnops.c:542) the buffer is idp->current.de.d_name; the write lands on struct isoreaddir tail fields (d_name ends at idp+816): currooff (name[17..24)), uio (name[25..32)), uio_off, eofflag, cookies (name[53..60) = 0), ncookies. Naive corruption panics in iso_uiodir+0x25 (panic_dents_serial.log); pointing idp->uio at a fake struct uio/iovec in userland (no SMAP) turns iso_uiodir()'s uiomove(dp, _DIRENT_DIRSIZ(dp), idp->uio) into bcopy(dirent, <any kernel address>, 152) (uio_segflg=UIO_SYSSPACE, uio_rw=UIO_READ — no td KASSERT on that path, kern_subr.c:105-108, :138-143). curroff set huge exits the readdir loop cleanly; cookies NULL avoids the cookie free; the syscall returns normally.
5. sysent hijack → ring0 → uid0. The copied dirent = 16-byte header + the NM-chain bytes (both attacker data; the ISO name only supplies the OOB tail smash). Target &sysent[71]-16: header lands on dead sysent[70] (sstk), chain byte 0..8 → sysent[71].{sy_narg=0, sy_rsize=4}, bytes 8..16 → sy_call = ring0 stub at 0x20000040, bytes 24..128 restore sysent[72..77] (vadvise/munmap/mprotect/ madvise/vhangup/vlimit) to their exact original table values so every live syscall (incl. sbrk/mmap used by exec) keeps working. syscall(71) executes the stub in ring0 (no SMEP): %gs:0 → gd_curthread(+8) → td_proc(+168) → p_ucred(+16) → cr_uid(+64)/cr_ruid(+160)/cr_svuid(+164) = 0, cr_ngroups(+68)=1, cr_caps(+176)=~0; returns 0 through the intact syscall frame. Result (run.log): uid after: 0 euid: 0 + contents of /root/df3156_rootproof (0400 root).

Why this is new (not DF-3146 / DF-0878 / DF-0879)

• DF-3146: negative wlen = length - 5 underflow → u_short wrap → 64KB rewind. Here every fragment length is ≥ 5 and every accumulation passes the maxlen check; the write offset is a positive legitimate chain length and the sink is the fallback writer, not altname's bcopy.
• DF-0878: loop-level entry-length upper-bound OOB reads (handlers reading past short entries). This is an OOB write caused by walk termination semantics, and my entry lengths are honest.
• DF-0879: unbounded CE chains / infinite loop. Two CE hops only.

Reproduction matrix (guest 6.5-DEVELOPMENT, x86_64, securelevel -1)

Fix kernel: patch -p1 < fix.diff, make -j8 nativekernel, make installkernel, reboot → #1: Mon Sep 7 07:47:17 UTC 2026.

PoC fixes vs the seed

No seed existed (new finding). Iterations that mattered: (1) even-length ISO names need the pad byte before the SUSP area or the walker starts one byte into the first field (cd9660_rrip.c:484-486); (2) the dirent that the hijacked uiomove copies is built from the NM-chain bytes, not the ISO name (the ISO name is consumed by the OOB tail smash); (3) the record's first name byte must not be 0/1 — cd9660_rrip_getname (:652-657) treats such records as "."/"..", skips the NM table row and calls defname at the base (no OOB); (4) d_type/d_unused2 of the dirent header are stale heap bytes, so the sysent alignment must keep the 16-byte header on dead fields.

Recommended fix

fix.diff (in this pack): rewind ana->outbuf -= *ana->outlen; *ana->outlen = 0; at the top of cd9660_rrip_defname() — the fallback always rebuilds the name at the caller's buffer base; the deltas are 0 on every legitimate path that reaches it. Defense-in-depth (not required for correctness): have cd9660_rrip_loop reset the output state whenever the walk terminates with ISO_SUSP_ALTNAME still pending.

Interactive root shell (2026-10-16 maintenance pass, run_shell.log)

The exploit now has a --shell mode (or DF3156_SHELL=1): after the same credential-zeroing syscall(71) and the rootproof read it execl("/bin/sh","sh") into a real interactive # shell — captured under script(1) on a pty in run_shell.log/run_shell.raw: tty-echoed commands, id → uid=0(root) gid=0(wheel) groups=0(wheel) inside the shell, rootproof re-read, touch /tmp/DF3156_OWNED landing 0:0-owned (verified from the ssh root context after exit), rc=0, guest stable. Two latent PoC defects were fixed to make the ending work: (1) the ring0 stub wrote cr_caps = ~0, but cr_caps is a restriction bitmap (sys/sys/caps.h: "negatives, i.e. restrictions") — ~0 is maximally restricted and made every post-surgery execve fail EACCES (the original run.log's exec'd id never printed for exactly this reason); the stub now writes 0 (unrestricted), after which setgid(0)/setuid(0) also run and exec works (run.2.log now shows the full uid=0(root) ... groups=0(wheel) id output in default mode too). (2) the kernel constants are build-specific: on the current with-src snapshot kernel (a later fix-validation rebuild, sysent=0xffffffff810cb880) the write lands 0x3f68 below the real sysent, the syscall(71) probe SIGSYSes, and the misdirected 152-byte write corrupts unrelated static data — reproducibly panicking at exit (funsetfd_locked+0x28, type 12); on the stock clean-install kernel (sysent=0xffffffff810c7900) every constant matches and the chain works first-try. Reproduce on the clean-install snapshot (vm.sh reset, not with-src) and re-derive constants from nm /boot/kernel/kernel when the kernel changes. One exploit run per fresh boot+mount remains the reliable pattern: a repeat run risks the OOB spill (the 131-byte name writes 66 bytes past the 880-byte isoreaddir into an adjacent kmalloc slot) hitting a live neighbor — observed once as a funsetfd_locked trap on process exit. The interactive-shell ending changes nothing about the finding or its fix: it is a userspace epilogue after the same verified primitive, so the validated fix.diff kernel stops it at stage 1 identically (the Sep 7 fix kernel #1 no longer exists on the current guest image — its snapshot was replaced by the with-src rebuild — so no new fix-kernel contrast run was made this pass; the original fix validation in fix_run_exploit.log stands).

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.