DF-2595 — ng_bpf missing zero-length-packet guard → bpf_filter type confusion

Verdict

REPRODUCED (code path confirmed reachable & exercised) but LATENT on the default guest: no observable panic or leak. The defective code path — a zero-length mbuf reaching bpf_filter() with buflen==0, which in the kernel makes bpf_filter() cast the flat data pointer to (struct mbuf *) and walk it as an mbuf chain — is unambiguously confirmed reached (line-by-line trace + recvFrames delta = 4 for 4 zero-length sends). But on the default 6.5-DEVELOPMENT #0 guest the stale mbuf data area read as the "fake struct mbuf" is benign (zeroed → fake m_next == NULL → m_xword() bails with merr=1 → bpf_filter returns 0), so there is no deterministic crash or kernel-memory disclosure. This is a confirmed-reachable latent type confusion / hardening gap: FreeBSD's ng_bpf has the guard, DragonFly's does not. FIX VALIDATED (rebuilt ng_bpf.ko, guard confirmed in disasm, clean before/after).

The bug (confirmed line-by-line)

ng_bpf_rcvdata() in sys/netgraph/bpf/ng_bpf.c:373 computes totlen = m->m_pkthdr.len and, with no guard for totlen == 0, hands totlen as both wirelen and buflen straight to bpf_filter() (ng_bpf.c:403):

int totlen = m->m_pkthdr.len;            /* line 376 */
...
if (m->m_next != NULL) { ...; data = buf; m_copydata(m, 0, totlen, data); }
else data = mtod(m, u_char *);           /* line 400 */
...
len = bpf_filter(hip->prog->bpf_prog, data, totlen, totlen);  /* line 403 */

In the kernel, bpf_filter() (sys/net/bpf_filter.c:174) treats buflen == 0 as the signal "the buffer p is actually an mbuf chain; traverse it". For every packet-load instruction the bounds check fails when buflen==0, and the guard if (buflen != 0) return 0; is false, so execution falls into the mbuf traversal that casts the flat buffer to a struct mbuf *:

case BPF_LD|BPF_W|BPF_ABS:                 /* bpf_filter.c:206 */
    k = pc->k;
    if (k > buflen || sizeof(int32_t) > buflen - k) {   /* true for any k when buflen==0 */
#ifdef _KERNEL
        int merr;
        if (buflen != 0)        /* <-- guard FALSE because buflen==0 */
            return 0;
        A = m_xword((struct mbuf *)p, k, &merr);   /* TYPE CONFUSION (line 214) */
        if (merr != 0)
            return 0;
        continue;

m_xword() (bpf_filter.c:85) then dereferences m->m_len, m->m_next, mtod(m) on the fake mbuf. The identical pattern applies to BPF_LD|BPF_H|BPF_ABS (m_xhalf, c:238), BPF_LD|BPF_B|BPF_ABS (MINDEX+mtod, c:255), and the BPF_IND variants. This mbuf-traversal fallback is intentional for live bpf(4) filtering (where p really is an mbuf and buflen==0 is the "use the chain" sentinel); ng_bpf mis-uses the API by always passing a flat buffer and forgetting to reject totlen==0. FreeBSD's ng_bpf_rcvdata has the totlen==0 guard; DragonFly's does not.

Trigger requires a packet-load program

The default hook program is { BPF_STMT(BPF_RET+BPF_K, 0) } — a bare return, no load instruction — so the default never reaches the confused path. The PoC installs a load+ret program first (BPF_LD|BPF_W|BPF_ABS, k=0 then BPF_RET|BPF_K).

Reachability / privilege

ng_bpf_rcvdata is reached via a netgraph data socket (PF_NETGRAPH SOCK_DGRAM). Building the graph (NGM_MKPEER ng_bpf, NGM_BPF_SET_PROGRAM) goes through the netgraph control socket, whose attach ngc_attach() (sys/netgraph/socket/ng_socket.c:172) gates on caps_priv_check(SYSCAP_RESTRICTEDROOT) = root. The data socket (ngd_attach, ng_socket.c:310) needs no privilege, but it can only SEND on a hook a root-built graph already wired up. So the bug trigger is root-reachable (a root firewall admin configuring an ng_bpf filter); an unprivileged user can only inject data on a graph a root already configured. (The finding prompt's "any user PF_NETGRAPH SOCK_DGRAM" is true for the data socket alone, not for graph setup.)

Reproduction (unpatched #0 kernel)

# /tmp/poc2595
[+] created socket node 'df2595' csock=3 dsock=4
[+] mkpeer ng_bpf 'df2595:out' -> bpf 'in'
[+] installed BPF program on bpf 'in': LD_W_ABS k=0; RET 0
[*] stats BEFORE: recvFrames=0 recvOctets=0
[*] sending 4 ZERO-LENGTH data items -> ng_bpf 'in' (totlen=0)...
[*] stats AFTER : recvFrames=4 recvOctets=0  (delta=4)
[+] CONFIRMED: zero-length data reached ng_bpf_rcvdata -> bpf_filter(buflen=0)
    -> type-confusion branch entered
[*] grooming mbuf pool: flooding 4000 pointer-shaped packets then re-sending zero-length...
[*] still alive — kernel survived grooming+zero-length flood

recvFrames += 4 for 4 zero-length sends proves ng_bpf_rcvdata was entered with m_pkthdr.len == 0, and the code trace proves that path reaches bpf_filter(prog, data, 0, 0) → the buflen==0 mbuf-traversal branch. No panic occurred: the mbuf's data area (read as the fake struct mbuf) is zeroed/benign on the default guest, so m_xword's m = m->m_next yields NULL → it returns merr=1 → bpf_filter returns 0. A targeted mbuf-pool grooming flood (4000 pointer-shaped packets interleaved with zero-length sends) did not land a stale mbuf whose residue dereferences to a fault — the MH_ALIGN(m, 0) data pointer points near the end of m_pktdat, which the grooming packets' bytes don't reach, so the fake fields stay zeroed.

To make this deterministically panic/leak one would need to defeat that alignment-dependent grooming window — a real but non-trivial exploit-dev task whose payoff is a kernel pointer deref from a root-only trigger. The defect is real and worth fixing as defense-in-depth regardless.

The fix (defense-in-depth, matches FreeBSD upstream)

Reject zero-length packets at the top of ng_bpf_rcvdata, before any data-pointer work and before bpf_filter is ever called:

if (totlen == 0) {
    NG_FREE_DATA(m, meta);
    return (0);
}

Standalone git apply-able diff: fix.diff.

Fix validation (rebuilt ng_bpf.ko, reloaded, re-ran same PoC)

• Before (unpatched #0 kernel + #0 module, sha b69ff3fd…): recvFrames delta = 4 — zero-length packets reach ng_bpf_rcvdata, get counted, and bpf_filter(buflen=0) is called → the type-confusion branch is entered.
• After (#0 kernel + rebuilt single-fix ng_bpf.ko, sha d6407950…): recvFrames delta = 0 — zero-length packets are dropped by the guard before the stats update and before bpf_filter is called. Disasm confirms: mov 0xb8(%rsi),%r12d (load totlen) → test %r12d,%r12d → je <ng_bpf_rcvdata+0x180> (early NG_FREE_DATA+return 0).
• No regression: non-zero packets are still filtered (recvFrames += 2 for two 32-byte packets on the patched module).
• Module rebuilt via cd /usr/src/sys/netgraph/bpf && make KERNBUILDDIR=… (module-only; MAKE_RC=0); kldunload ng_bpf (rc=0, graph torn down) → kldload ng_bpf (rc=0). No reboot needed (ng_bpf is safely unloadable, unlike ipfw3).

fix_status = fixed (the dangerous code path is now deterministically short-circuited; clean before/after on the recvFrames signal; no regression).

Files

• poc.c — builds ng_bpf graph with a packet-load program, sends zero-length items, queries NGM_BPF_GET_STATS to prove the path, and grooms the mbuf pool.
• build.sh / run.sh — exact build & run (run as root; loads ng_socket + ng_bpf).
• run.log — baseline run (recvFrames delta=4, type-confusion path entered, no panic).
• fix_run.log — patched-module run (recvFrames delta=0, path short-circuited).
• fix_build.log — module rebuild + disasm (MAKE_RC=0, guard confirmed).
• env.txt — guest uname / cc / patched sha / kldstat.
• fix.diff — the standalone git-apply-able zero-length guard.
• manifest.json — artifact catalog.