DF-0011 — PoC

nopasscred_panic.c — local DoS via the missing sbcreatecontrol() NULL check in the SO_PASSCRED synthesis path of uipc_send(). flood_trigger.c is an auxiliary hold-open variant used during analysis.

The bug

uipc_send() SOCK_DGRAM, sys/kern/uipc_usrreq.c:694-699:

if (ncon == NULL) {                 /* no existing SCM_CREDS cmsg found */
    ncon = sbcreatecontrol(&cred, sizeof(cred), SCM_CREDS, SOL_SOCKET);
    unp_internalize(ncon, msg->send.nm_td);   /* ncon may be NULL */
    *mp = ncon;
}

sbcreatecontrol() (sys/kern/uipc_sockbuf.c:585-604) returns NULL when its m_getl(..., M_NOWAIT, MT_CONTROL, 0, NULL) fails — i.e. when the plain "mbuf" objcache (sys/kern/uipc_mbuf.c:798, nmbufs deep) is exhausted. The return is never checked, so unp_internalize(NULL) runs and at uipc_usrreq.c:1706 does cm = mtod(control, ...) = load of mh_data from a NULL mbuf ⇒ offsetof(struct m_hdr, mh_data) == 0x10 ⇒ page fault at vaddr 0x10 in kernel mode ⇒ panic.

Trigger

An unprivileged local user who (a) exhausts the plain "mbuf" objcache and (b) sends to an AF_UNIX SOCK_DGRAM receiver that has SO_PASSCRED set, without an SCM_CREDS cmsg.

How the precondition is met (the crux): each AF_UNIX SOCK_DGRAM datagram pinned in a receiver buffer consumes 2 plain mbufs (MT_CONTROL + MT_SONAME) but only 1 pkthdr mbuf (MT_DATA data). Pinned plain:pkthdr ratio is therefore 2:1. Exhausting the 72904-deep plain cache pins only ~36500 pkthdr, leaving the pkthdr cache ~half empty — so the trigger's data pkthdr mbuf still allocates (M_WAITOK in sosend) and execution reaches sbcreatecontrol(), whose plain m_get(M_NOWAIT) then FAILS ⇒ NULL ⇒ panic.

The PoC runs a pinner thread (ramp plain-mbuf pressure) concurrently with a trigger thread (fire no-control SO_PASSCRED sends), so a trigger send lands on the instant of plain-cache exhaustion instead of overshooting into a wedge.

Build

cc -o nopasscred_panic nopasscred_panic.c -lpthread

Run

As an unprivileged user (this PANICS the kernel — local DoS):

./nopasscred_panic

Expected output (bug present)

A kernel panic on the serial console:

Warning: objcache(mbuf) exhausted on cpuN!
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x10
Stopped at      unp_internalize.isra.12+0x11:   movq    0x10(%rdi),%rbx

(The finding markdown guessed fault address 0x0; the real address is 0x10, the mh_data offset in struct m_hdr — same bug, sharper address.) Reproduced twice from independent fresh vm.sh reset boots with an identical signature. On a patched kernel (NULL check added) the trigger send returns ENOBUFS instead and the program prints "no panic".

DF-0011 — VERDICT

Verdict: REPRODUCED (unprivileged local DoS via NULL-deref kernel panic in unp_internalize). Impact: panic (denial of service). Confidence: certain. Reproduced twice from independent fresh vm.sh reset boots with an identical, mechanism-matching panic signature.

Mechanism (trigger → primitive → effect)

1. Missing NULL check (root cause). In uipc_send, SOCK_DGRAM, sys/kern/uipc_usrreq.c:694-699, when no pre-existing SCM_CREDS cmsg is present and the receiver has SO_PASSCRED set: c if (ncon == NULL) { ncon = sbcreatecontrol(&cred, sizeof(cred), SCM_CREDS, SOL_SOCKET); unp_internalize(ncon, msg->send.nm_td); /* ncon used UNCHECKED */ *mp = ncon; } The return of sbcreatecontrol() is never tested.

2. sbcreatecontrol can return NULL. sys/kern/uipc_sockbuf.c:585-604: c if (CMSG_SPACE(size) > MCLBYTES) return (NULL); m = m_getl(CMSG_SPACE(size), M_NOWAIT, MT_CONTROL, 0, NULL); if (m == NULL) return (NULL); For SCM_CREDS, size = sizeof(struct cmsgcred) = 84, so CMSG_SPACE ~ 104 < MCLBYTES and the first check passes. The only NULL path is the m_getl(M_NOWAIT, MT_CONTROL) failure. MT_CONTROL with this size takes the plain-mbuf branch of m_getl (sys/sys/mbuf.h:589-601), i.e. m_get() from the plain "mbuf" objcache (sys/kern/uipc_mbuf.c:798, limit nmbufs; 72904 on this guest per netstat -m). That objcache returns NULL when exhausted.

3. NULL deref at offset 0x10. unp_internalize (:1702) opens with c struct cmsghdr *cm = mtod(control, struct cmsghdr *); /* :1706 */ mtod(m, t) = (t)((m)->m_data) (sys/sys/mbuf.h:73) and m_data == m_hdr.mh_data (:221). With control == NULL, this is a load of mh_data from address NULL + offsetof(struct m_hdr, mh_data). struct m_hdr (sys/sys/mbuf.h:79-90) is mh_next[8] + mh_nextpkt[8] + mh_data ⇒ offsetof(mh_data) == 16 == 0x10. ⇒ page fault at virtual address 0x10 in kernel mode ⇒ panic.

Trigger strategy (how the precondition is met by an unprivileged user)

The hard part is making m_get(M_NOWAIT) fail. The plain "mbuf" cache is ~72904 deep and NMBUFS_MIN = NMBUFS/2 ≈ 36516, so it cannot be shrunk at runtime below ~36500. The decisive observation: each AF_UNIX SOCK_DGRAM datagram pinned in a receiver buffer accounts for 2 plain mbufs but only 1 pkthdr mbuf — one MT_CONTROL (the cmsg) plus one MT_SONAME (the source sockaddr recorded by ssb_appendaddr) for the data's one MT_DATA pkthdr. So the pinned plain:pkthdr ratio is 2:1. Exhausting the 72904-deep plain cache pins only ~36500 pkthdr mbufs, leaving the pkthdr cache ~half empty. The trigger's no-control send() therefore successfully allocates its data pkthdr mbuf (m_getl(M_WAITOK) in sosend, uipc_socket.c:866), proceeds into uipc_send's SO_PASSCRED block, and calls sbcreatecontrol() whose plain m_get(M_NOWAIT) FAILS ⇒ NULL ⇒ unp_internalize(NULL) ⇒ fault at 0x10.

The PoC runs this concurrently: a pinner thread ramps the pinned-datagram count while a trigger thread continuously fires no-control SO_PASSCRED sends, so a trigger send lands on the instant of plain-cache exhaustion (but before the pkthdr cache is also starved), deterministically hitting the NULL path. (A naive "pin everything, then fire" loop instead overshoots into a full memory-pressure wedge without reaching the trigger — that is the race the finding flagged as AC:H.)

Evidence (decisive, reproduced twice)

panic.txt holds the full serial-console excerpt from dfbsd-qemu/boot.log. Both fresh-reset reproductions produced an identical signature:

login: Warning: objcache(mbuf) exhausted on cpu1!
Fatal user address access from kernel mode from nopasscred_panic at ffffffff806cdac1

Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic id = 1
fault virtual address   = 0x10
fault code      = supervisor read data, page not present
instruction pointer = 0x8:0xffffffff806cdac1
current process     = 1468           (unprivileged: nopasscred_panic, run as maxx)
kernel: type 12 trap, code=0

Stopped at      unp_internalize.isra.12+0x11:   movq    0x10(%rdi),%rbx
db>

This matches the cited path exactly: - objcache(mbuf) exhausted ⇒ the NULL-return precondition of sbcreatecontrol is met. - fault virtual address = 0x10 ⇒ offsetof(struct m_hdr, mh_data). (The finding markdown guessed 0x0; the real fault address is 0x10 — the mh_data offset, not the mbuf base pointer. Same bug, sharper address.) - Stopped at unp_internalize.isra.12+0x11: movq 0x10(%rdi),%rbx with %rdi == 0 (NULL control) ⇒ precisely the mtod(control,…) load at uipc_usrreq.c:1706. - current process = 1468 ⇒ the unprivileged trigger, confirming local DoS.

PoC changes

The seeded nopasscred_panic.c had (a) a compile bug (#define N SOCK 4096 — NSOCK undeclared) and (b) a flawed exhaustion strategy that targeted the pkthdr cache (datagram data) rather than the plain cache that sbcreatecontrol uses, so it only wedged the guest instead of panicking. I rewrote it to (1) pin plain mbufs via SCM_CREDS-bearing datagrams at the 2:1 plain:pkthdr ratio, and (2) fire the no-control SO_PASSCRED trigger concurrently during the ramp so it lands on the exhaustion crossover instead of overshooting into a wedge. flood_trigger.c is retained as an auxiliary/earlier hold-open variant. The improved PoC reproduces the panic from fresh resets.

Exploit chain

Not a memory-corruption class — a clean NULL deref (read of mh_data from a NULL mbuf). No integrity/confidentiality impact; ceiling = reliable local DoS (panic). current process = <unprivileged trigger> and panic from nopasscred_panic confirm unprivileged reachability.

Recommended fix

fix.diff (git-apply-able, git apply --check verified) adds the missing NULL check at sys/kern/uipc_usrreq.c:694-699:

if (ncon == NULL) {
    ncon = sbcreatecontrol(&cred, sizeof(cred), SCM_CREDS, SOL_SOCKET);
    if (ncon == NULL) {
        error = ENOBUFS;
        unp_free(unp2);     /* drop ref the normal SOCK_DGRAM path holds */
        break;              /* -> function epilogue frees m & control    */
    }
    unp_internalize(ncon, msg->send.nm_td);
    *mp = ncon;
}

unp_free(unp2) is called explicitly because the break skips the normal path's unp_free(unp2) at :717; the function's release: epilogue (after the switch) already frees m and control and disposes control when error != 0, so no resource leak. This supersedes the finding markdown's ## Recommended fix (which used a bare break without unp_free(unp2), leaking an unp2 reference) while preserving its intent.

Fix validation (Phase 8 — built + booted single-fix kernel)

Build: Applied fix.diff to clean with-src /usr/src (patch -p1 succeeded at line 694), built make -j6 nativekernel KERNCONF=X86_64_GENERIC (rc=0, ~4 min), installed kernel.stripped → /boot/kernel/kernel (sha256 ae0ecfae...), rebooted. Booted kernel: #1 Thu Jul 2 18:42:06 UTC 2026 (baseline was #0 Thu Jul 2 06:02:54). Full build log in fix_build.log.

Before (unpatched #0): PoC panicked the kernel within seconds of plain-cache exhaustion — identical to the original reproduction:

Warning: objcache(mbuf) exhausted on cpu0!
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x10
Stopped at unp_internalize.isra.12+0x11: movq 0x10(%rdi),%rbx

Guest DOWN at DDB db> prompt. (run.log, panic.txt.)

After (patched #1) — Run 1: PoC pinned 76950 dgrams, the Warning: objcache(mbuf) exhausted warnings fired (proving the allocation-failure precondition was met), but NO panic — guest stayed UP, the trigger process kept firing sends for 2+ minutes under exhaustion. On the unpatched kernel the panic fires within seconds.

After (patched #1) — Run 2 (clean reboot): PoC ran to completion: trigger fired 100,710,079 no-control SO_PASSCRED sends under mbuf exhaustion, exited 2 cleanly, guest healthy (Fatal trap/Stopped at absent from boot.log).

Verdict: fix_status = FIXED. The before/after contrast is unambiguous: same PoC, same workload, same mbuf-exhaustion precondition → panic on #0, no panic on #1. The NULL check after sbcreatecontrol() converts the NULL-deref into a graceful ENOBUFS return, closing the bug. (fix_run.log.)