Summary

ng_iface_output treats dst->sa_data as an out-of-band address-family source when dst->sa_family == AF_UNSPEC, but for DLT_NULL BPF writes (the link type ng_iface uses), bpf_movein never initializes sa_data, so the kernel reads 4 bytes of uninitialized stack into af. If the low byte of that garbage is 0, ng_iface_bpftap's KASSERT(family != AF_UNSPEC) fires and the kernel panics. INVARIANTS is enabled in the default X86_64_GENERIC kernel, so this is a local- privileged denial-of-service via a single legitimate write() to /dev/bpf on an ng_iface.

Root cause

In ng_iface_output (sys/netgraph7/iface/ng_iface.c:428-431):

428:    if (dst->sa_family == AF_UNSPEC) {
429:        bcopy(dst->sa_data, &af, sizeof(af));   /* af is uint32_t */
430:        dst->sa_family = af;                    /* sa_family_t is __uint8_t! */
431:    }
434:    ng_iface_bpftap(ifp, m, dst->sa_family);

For ng_iface the BPF link-layer type is DLT_NULL (constructor line 625: bpfattach(ifp, DLT_NULL, sizeof(u_int32_t))). For DLT_NULL, bpf_movein (sys/net/bpf.c:189-193) sets sockp->sa_family = AF_UNSPEC and hlen=0, so the if (hlen != 0) block at bpf.c:253-275 that would normally bcopy the link header into sa_data is skipped entirely. The struct sockaddr dst declared in bpfwrite (sys/net/bpf.c:619) is an uninitialized stack local; bpfwrite passes &dst straight to ifp->if_output (sys/net/bpf.c:598). So dst->sa_data is whatever garbage the stack happens to contain.

The bcopy reads 4 bytes of that garbage into af, then dst->sa_family = af truncates to one byte. If the low byte is 0, dst->sa_family becomes AF_UNSPEC, and ng_iface_bpftap (line 481) panics:

481:    KASSERT(family != AF_UNSPEC, ("%s: family=AF_UNSPEC", __func__));

KASSERT is enabled under INVARIANTS (sys/sys/systm.h:94-96), and INVARIANTS is in the default X86_64_GENERIC kernel config (sys/config/X86_64_GENERIC).

The correct semantics (already implemented in newer FreeBSD ng_iface.c) is to read the AF from the leading 4 bytes of the mbuf via m_copydata(m, 0, sizeof(af), &af) and then m_adj(m, sizeof(af)) to strip the DLT_NULL link-layer word — neither of which this file does, so even when af is non-zero the packet is forwarded into netgraph with the AF prefix still attached, corrupting the peer's view of the payload.

Threat model & preconditions

• Attacker position: local user with write access to /dev/bpf* (root on a default DragonFly install; or any principal granted BPF via devfs rules / group network on hardened setups).
• Privileges gained or impact: local denial of service (kernel panic). The KASSERT fires whenever the stack garbage at &dst.sa_data happens to have a zero low byte — roughly 1/256 probability per write on x86_64, so a tight write() loop panics the machine within seconds. No confidentiality or integrity impact.
• Required config or capabilities: write access to /dev/bpf*; an ng_iface interface attached (common in ng_pppoe / ng_l2tp / ng_nat topologies).
• Reachability: write() to /dev/bpfN (bound to an ng_iface) → bpfwrite → ifp->if_output → ng_iface_output → reads uninitialized dst->sa_data → ng_iface_bpftap → KASSERT.

Proof of concept

PoC source: findings/poc/DF-0607/df-bpf-panic.c

Build & run

cc -o df-bpf-panic df-bpf-panic.c
# one-time topology:
ngctl mkpeer iface dummy inet    # creates ng0
sudo ./df-bpf-panic

Expected output

Kernel panic on the console and in /var/crash:

panic: assertion "family != AF_UNSPEC" failed in ng_iface_bpftap at sys/netgraph7/iface/ng_iface.c:481

On a non-INVARIANTS kernel the same code still reads 4 bytes of uninitialized stack and (when af != 0) forwards a 4-byte-AF-corrupted mbuf into the inet/inet6 hook.

Impact

• Blast radius: any DragonFly system exposing /dev/bpf* with an ng_iface interface (VPN concentrators, routers, test setups).
• Severity rationale: Low. Requires BPF write access (root), panic is probabilistic (~1/256 per write). No info leak or code execution. CVSS 3.1 base ≈ 5.0.
• Reliability: probabilistic on INVARIANTS kernels (~1/256 per write); deterministic panic with a tight loop within seconds. On non-INVARIANTS kernels, silent payload corruption.

Recommended fix

Read the AF from the leading 4 bytes of the mbuf (DLT_NULL convention) instead of from dst->sa_data, and strip those 4 bytes so the downstream hook receives the actual protocol payload. This matches the newer FreeBSD ng_iface.c semantics.

--- a/sys/netgraph7/iface/ng_iface.c
+++ b/sys/netgraph7/iface/ng_iface.c
@@ -425,12 +425,20 @@ ng_iface_output(struct ifnet *ifp, struct mbuf *m,
    uint32_t af;
    int error;

    /* Check interface flags */
    if (!((ifp->if_flags & IFF_UP) && (ifp->if_flags & IFF_RUNNING))) {
        m_freem(m);
        return (ENETDOWN);
    }

-   /* BPF writes need to be handled specially. */
+   /*
+    * BPF writes arrive with dst->sa_family == AF_UNSPEC.  For our
+    * DLT_NULL link type the actual address family is carried in the
+    * leading 4 bytes of the mbuf; bpf_movein() does not populate
+    * dst->sa_data, so we must not read from it.
+    */
    if (dst->sa_family == AF_UNSPEC) {
-       bcopy(dst->sa_data, &af, sizeof(af));
-       dst->sa_family = af;
+       if (m->m_pkthdr.len < sizeof(af)) {
+           m_freem(m);
+           return (EINVAL);
+       }
+       m_copydata(m, 0, sizeof(af), (caddr_t)&af);
+       m_adj(m, sizeof(af));
+       dst->sa_family = (sa_family_t)af;
    }

    /* Berkeley packet filter */

Independently, the KASSERT(family != AF_UNSPEC, ...) at line 481 documents an internal invariant that the public ng_iface_output path can violate; even with the fix above, replacing that KASSERT with a graceful if (family == AF_UNSPEC) return; would make the helper robust against future callers that fail to rewrite AF_UNSPEC.

References

• sys/net/bpf.c:189-193, 253-275, 598, 619 — bpf_movein sets sa_family=AF_UNSPEC and hlen=0 for DLT_NULL; bpfwrite passes uninitialized &dst to if_output.
• sys/netgraph7/iface/ng_iface.c:625 — bpfattach(ifp, DLT_NULL, ...).
• sys/config/X86_64_GENERIC:56 — default-config INVARIANTS.

Timeline

• 2026-07-02 Discovered during automated DragonFlyBSD kernel security audit.
• 2026-07-02 Reported to DragonFlyBSD security contact (pending).