Summary

ng_deflate_compress() mirrors the decompress underflow (DF-0638): it upper-bounds inlen at line 456 but never lower-bounds it. A 0-length mbuf on the comp hook reaches the else-branch at line 471-473 (inbuf[0]==0 on a fresh node) and computes avail_in = inlen - 1 = (int)-1 → (uInt)0xFFFFFFFF. deflate() at line 479 then reads OOB kernel heap starting at inbuf+1 and, uniquely on this path, the (encoded) leaked bytes are written to outbuf and shipped to the remote peer via m_devget+NG_FWD_NEW_DATA (:507,:366) — a local-to-remote kernel heap information leak.

Root cause

ng_deflate.c:451: inlen = m->m_pkthdr.len (int). Line 456: rejects only inlen > 4096. Line 463: m_copydata copies 0 bytes for a 0-length mbuf → inbuf unchanged. Line 468: tests inbuf[0]; on a fresh M_ZERO node inbuf[0]==0 so the else branch is taken. Lines 472-473: next_in = inbuf+1, avail_in = inlen - 1 = (int)-1 → (uInt)0xFFFFFFFF. Line 479: deflate() reads OOB from inbuf+1 for up to ~4 GiB.

Unlike the decompress path, the compressed output crosses the trust boundary to a cooperating remote peer.

Threat model & preconditions

• Triggering requires privileged topology access: the normal ng_ppp outbound path always prepends a protocol byte (ng_ppp_addproto, ng_ppp.c:2391-2401), so inlen >= 1 there and the bug is dormant on default topologies. It becomes reachable when something connects to the deflate comp hook directly or emits a degenerate frame — i.e. an attacker who can manipulate the netgraph topology (typically root via /dev/ngctl).
• Impact: kernel heap OOB read (potential panic if the walk hits an unmapped page) plus local-to-remote info leak of heap-derived bytes encoded in the compressed output.

Recommended fix

Add if (inlen < 1) { ... return (EINVAL); } before m_copydata at line 456, symmetric to the decompress fix.

References

• sys/netgraph7/deflate/ng_deflate.c:451,456,472-473,479 — the underflow and deflate() OOB sink.
• DF-0638 — the same-class bug on the decompress path.

Timeline

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