DF-0785 — ntfs_ntlookupfile heap buffer overflow — PoC

Reproduction package for DragonFlyBSD ntfs_ntlookupfile heap OOB write (CWE-787). Verified on 6.5-DEVELOPMENT #0 (X86_64_GENERIC, INVARIANTS ON).

Bug

sys/vfs/ntfs/ntfs_subr.c ntfs_ntlookupfile:

blsize = vap->va_a_iroot->ir_size;                 /* :867  allocation size  */
rdsize = vap->va_datalen;                          /* :868  copy size        */
...
rdbuf = kmalloc(blsize, M_TEMP, M_WAITOK);         /* :888                   */
error = ntfs_readattr(ntmp, ip, NTFS_A_INDXROOT, "$I30",
                      0, rdsize, rdbuf, NULL);      /* :890-891 copies rdsize */

ir_size (an on-disk u_int32_t inside the resident $INDEX_ROOT header) sizes the buffer; va_datalen (a separate on-disk field, the resident attribute data length) sizes the copy. No check rdsize <= blsize exists. A crafted NTFS image sets ir_size < va_datalen, so ntfs_readattr's memcpy writes rdsize attacker-controlled bytes into a blsize-byte slab object → heap overflow.

The sibling reader ntfs_ntreaddir sizes correctly:

fp->f_dirblbuf = kmalloc(max(vap->va_datalen, fp->f_dirblsz), M_NTFSDIR, M_WAITOK); /* :1105 */

Note ntfs_readattr's own guard (ntfs_subr.c:1671-1676, roff + rsize > va_datalen) does not stop this: the buggy call passes rsize = rdsize = va_datalen, so rdsize > va_datalen is always false. The guard never sees the buffer size.

Trigger

Mount a crafted NTFS image (root $INDEX_ROOT with ir_size < va_datalen), then issue any non-. / non-.. name lookup into the volume — stat /mnt/x, ls /mnt/realfile, etc. — which reaches ntfs_lookup → ntfs_ntlookupfile.

Mount is privileged (SYSCAP_RESTRICTEDROOT); the post-mount name lookup is unprivileged — same threat model as the ext2/hammer image findings (vfs.usermount=1 + a root-created attacker-owned image is a realistic precondition).

Reproduce

./build.sh                       # craft image + compile harnesses (guest cc)
./run.sh                         # A) harness before/after, B) live kernel overflow

run.sh does two things:

A. Deterministic harness (harness.c / harness_fixed.c) — transcribes the exact kmalloc(blsize) + ntfs_readattr(rdsize) copy with a guard-paged allocator and faults byte-exactly at the overflow. No slab luck required. - unfixed: Segmentation fault (exit 139) — overflow into PROT_NONE page. - fixed: clean completion (exit 0) — kmalloc(max(blsize,rdsize)) fits.

B. Live kernel overflow (unfixed ntfs.ko) — mount the crafted image then ~200 unprivileged name lookups; the heap overflow corrupts the M_TEMP slab free-list and the periodic slab_cleanup timer trips the INVARIANTS zone-alignment assertion:

panic: assertion "(((intptr_t)chunk ^ (intptr_t)z) & ZoneMask) == 0"
       failed in chunk_mark_free at kern_slaballoc.c:1675
chunk_mark_free() -> slab_cleanup() -> slotimer_callback() -> softclock_handler()

Expected

Impact

Heap OOB write, fully attacker-controlled content (the crafted resident $INDEX_ROOT data), attacker-controlled size (ir_size picks the slab bucket, va_datalen picks the overflow extent). On GENERIC INVARIANTS a single lookup corrupts silently (DragonFly slab tracks allocation in a zone bitmap and has no content canary); under slab churn it panics. Either way it is a groomable arbitrary-write primitive in a heavily-used zone (M_TEMP) — the classic material for uid=0 given the audit guest's SMAP/SMEP/KASLR-off posture.

Fix

findings/poc/DF-0785/fix.diff — one line, matching the sibling ntfs_ntreaddir:

-   rdbuf = kmalloc(blsize, M_TEMP, M_WAITOK);
+   rdbuf = kmalloc(max(blsize, rdsize), M_TEMP, M_WAITOK);

Validated by rebuilding ntfs.ko with the fix, hot-swapping it, and re-running the identical workload: no panic, guest stays up (fix_run.log).

DF-0785 — Verdict

REPRODUCED — uid=0 (local unprivileged → root) on the default GENERIC kernel.

A heap OOB write in ntfs_ntlookupfile (CWE-787) is a groomable, fully attacker-controlled arbitrary heap write that was escalated to a reliable maxx(uid 1001) → uid=0(root) privilege escalation on 6.5-DEVELOPMENT #0 (X86_64_GENERIC, INVARIANTS ON, SMAP/SMEP/KASLR all OFF), via a userspace-only chain (no kldload, no setuid helper, no INVARIANTS-OFF). Reproduced on two independent fresh-reset boots (run.chain1.log, run.chain2.log). The prior panic/corruption impact is superseded — uid0 is the demonstrated ceiling.

Root cause (confirmed, path:line)

sys/vfs/ntfs/ntfs_subr.c, ntfs_ntlookupfile:

• :867 blsize = vap->va_a_iroot->ir_size; — ir_size is an on-disk u_int32_t inside the resident $INDEX_ROOT attribute header.
• :868 rdsize = vap->va_datalen; — a separate on-disk value (resident attribute data length, a_r.a_datalen).
• :888 rdbuf = kmalloc(blsize, M_TEMP, M_WAITOK); — buffer sized by ir_size.
• :890-891 ntfs_readattr(... rdsize ... rdbuf) — copies rdsize bytes. No rdsize <= blsize check. When ir_size < va_datalen, the resident $INDEX_ROOT data (attacker-controlled) overflows the blsize-byte slab object by va_datalen - ir_size bytes into the next slab chunk in the same zone page. ntfs_readattr's own guard (:1671, roff+rsize>va_datalen) cannot catch this — the buggy call passes rsize=rdsize=va_datalen, so the test is va_datalen>va_datalen (always false).

The sibling reader already does it right: ntfs_ntreaddir:1105 kmalloc(max(vap->va_datalen, fp->f_dirblsz), M_NTFSDIR, M_WAITOK);

The primitive: write size = va_datalen, overflow extent = va_datalen-ir_size, content of every byte attacker-chosen, slab bucket attacker-chosen via ir_size, destination = the physically-next slab chunk in the same zone. DragonFly's slab (kern_slaballoc.c) selects zones by size only (shared across all M_* types), has no content canary/redzone (state is a per-zone bitmap, :1654-1683; use_weird_array only poisons freed chunks, never verifies), so a single overflow into a live victim is silent on GENERIC (INVARIANTS catches only free-list corruption later, under churn — that is the panic path).

Threat model / reachability

mount_ntfs is SYSCAP_RESTRICTEDROOT → the mount itself needs root (the standard filesystem-image threat model: an admin mounts / makes mountable an attacker-owned NTFS image — e.g. a USB stick, forensic image, or vfs.usermount=1 + a root-created image chowned to the user). Post-mount, the name-lookup trigger (ntfs_lookup → ntfs_ntlookupfile) is unprivileged — every step of the chain after the mount runs as maxx (uid 1001). The goal and result: maxx → uid=0.

The escalation chain (chain.c, sc.S)

Bucket / victim selection. Seat rdbuf in slab zone 34 (704-byte chunks) — the same zone as struct socket (socreate: kmalloc(sizeof(struct socket), M_SOCKET); sizeof(struct socket)=696 → zone 34). Set ir_size/blsize=704, va_datalen=744 ⇒ a 40-byte overflow into the next live socket covering so_pcb(8)=0, so_proto(16)=&forged_protosw, so_head(24)=0, so_port(32)=&forged_lwkt_port. (struct file/f_ops is in the separate kmalloc_obj objcache pool and is unreachable; struct socket is plain kmalloc → same zones as M_TEMP.)

Why so_port, not so_proto. The DragonFly socket layer dispatches so_proto->pr_usrreqs->pru_* and pr_ctloutput via lwkt netmsg to the netisr thread (uipc_msg.c so_pr_ctloutput → lwkt_domsg(so->so_port, …), and lwkt_thread_putport always returns EASYNC → the handler runs in the netisr thread context, not the caller's). netisr has no mapping of our user-space shellcode page, so hijacking so_proto's function pointers cannot fetch our shellcode. Instead we hijack so_port (a struct lwkt_port *): lwkt_domsg → lwkt_beginmsg(port,msg) = port->mp_putport(port,msg) (msgport.h, lwkt_msgport.c:80) — a synchronous direct call in the originating process context (maxx's getsockopt), where our user-space mappings are live. We forge so_port->mp_putport = &shellcode.

Grooming. Spray 5000 UDP sockets to densely fill zone-34 across CPUs, then close every 5th to punch holes each flanked by live sockets. Each stat /mnt/x runs ntfs_ntlookupfile ⇒ one 40-byte overflow that, when rdbuf lands in a hole, corrupts the live socket immediately after it (so_port → forged port). Then getsockopt(fd, IPPROTO_IP, IP_TTL) on every live socket: the corrupted one routes sogetopt (sopt->sopt_level != SOL_SOCKET && so->so_proto->pr_ctloutput != NULL) → so_pr_ctloutput → lwkt_domsg(forged_port, msg) → forged_port->mp_putport = shellcode.

Conversion shellcode (sc.S, 157 bytes, in maxx context). Walks procglob[mypid & 0xff].allproc (procglob=0xffffffff81193640, allproc.lh_first@+0x20), finds our proc (p_list.le_next@0, p_pid@92), and zeroes its p_ucred(16) uid fields — cr_uid@64, cr_ngroups@68, cr_groups@72, cr_ruid@160, cr_svuid@164, cr_rgid@168, cr_svgid@172, cr_caps@176 — then returns 0 (non-EASYNC) so lwkt_domsg marks the msg done and getsockopt returns cleanly. No SMAP ⇒ kernel reads our forged protosw/port pages; no SMEP ⇒ kernel executes our shellcode page; no KASLR ⇒ all kernel addresses fixed. mypid is patched into a fixed user page (0x13372000) read by the shellcode.

Landing. On the next syscall entry the kernel re-syncs td_ucred from p_ucred (thread.h:279) → geteuid()==0 → setresuid(0,0,0) normalises → exec /bin/sh ⇒ root shell.

[chain] pid=2218 uid=1001 euid=1001
[chain] shellcode @ 0x13371000 (157 B); forged protosw @ 0x13372800; forged port @ 0x13373000 (mp_putport->shellcode)
[chain] sprayed 5000 sockets (zone-34 / struct socket)
[chain] punched holes; 4000 live sockets remain
[chain] *** ROOT ACQUIRED *** uid=0 euid=0
uid=0(root) gid=0(root) groups=0(root)
after setresuid: uid=0(root) gid=0(wheel) groups=0(wheel)
CHAIN_SUCCESS_UID0

Reproduced from a fresh vm.sh reset with-src (run.chain2.log) — not leaked state. The guest goes down shortly after success (post-exploitation collateral: zone-34 sockets whose so_port was redirected to user pages get touched by kernel cleanup / process exit), but the escalation (id→root, setresuid success) is already demonstrated. The grooming is probabilistic and typically succeeds within ~24 overflows; on GENERIC, overflows that instead hit free chunks corrupt the free list and surface as the chunk_mark_free:1675 / BADFREE2 INVARIANTS panic (the original panic impact) — that is the same bug manifesting destructively rather than exploitatively.

Fix

fix.diff — one line, matching the sibling ntfs_ntreaddir:1105:

-   rdbuf = kmalloc(blsize, M_TEMP, M_WAITOK);
+   rdbuf = kmalloc(max(blsize, rdsize), M_TEMP, M_WAITOK);

Fix validation (Phase 8) — fixed

Same #0 GENERIC kernel, hot-swapped a single-fix ntfs.ko built from the patched /usr/src (fix_build.log, cc 8.3, -Werror, rc=0; loaded-module disasm shows the max() materialise as cmovae). Re-ran the identical chain + crafted image:

max(blsize,rdsize)=max(704,744)=744 ⇒ kmalloc(744)→768-byte buffer, 744-byte copy ⇒ no overflow ⇒ no socket is ever corrupted ⇒ no so_port hijack ⇒ no shellcode ⇒ no escalation. fix_status = fixed. The fix supersedes/matches the finding markdown's proposal.

(Note: a separate, minor ntfs robustness issue exists under extreme malformed- image lookup churn — after ~60–80 lookups the scan path faults in ntfs_ntlookupfile; it is present with and without the fix, is a DoS not an escalation, and is out of scope for DF-0785's overflow. It would warrant its own finding.)

Files