DF-3461 — in6_cksum() sanity check bypassable via u32 wrap of off + len

Severity: Info (defense-in-depth; no in-tree caller can reach it) File: sys/netinet6/in6_cksum.c:116-158

Build / run (guest, DragonFly 6.5-DEVELOPMENT, stock kernel #0)

ssh dfbsd 'cat > /tmp/wrap_demo.c' < wrap_demo.c
vm.sh run_root 'cd /tmp && cc -O2 -Wall -o wrap_demo wrap_demo.c && ./wrap_demo'

Expected output

off=0xffffffff len=41 -> off+len=0x00000028 (40) wrapped=1
m->m_pkthdr.len=100: PASSES — sanity check BYPASSED
after walk: m=0x0 off=0xffffff9b -> w = mtod(m)+off = read (struct mbuf*)NULL->m_data -> kernel panic

This is a userland arithmetic mirror of the kernel code path, not a kernel reproduction: the finding is Info/unreachable, so no kernel PoC was run (a KLD that called in6_cksum(m, nxt, 0xFFFFFFFF, 41) would panic the guest — proving only what the mirror already shows).

What it demonstrates

1. in6_cksum.c:116: m->m_pkthdr.len < off + len — off and len are u_int32_t; off + len wraps mod 2^32, the comparison uses wrapped arithmetic, the "sanity" panic does not fire.
2. The offset walk (:150-156) exhausts the chain with off still huge, m == NULL.
3. :157-158: w = mtod(m, ...) + off; mlen = m->m_len - off; dereference the NULL mbuf → low-page fault → panic (not a controlled panic message).

Why Info

Every in-tree caller derives off/len from bounded quantities (u16 ip6_plen after the ip6_input.c:628-638 clamp/trim, plus each transport's IP6_EXTHDR_CHECK pull-up) — none can produce a wrapping sum. See VERDICT.md for the full caller matrix.

VERDICT — DF-3461

Status: untested at kernel level (by design — Info/unreachable finding); arithmetic mirror reproduced on guest toolchain. Impact: none (hardening). Confidence: certain (code behavior); reachability from any in-tree caller: none.

Root cause

sys/netinet6/in6_cksum.c:116:

if (m->m_pkthdr.len < off + len) {
        panic("in6_cksum: mbuf len (%d) < off+len (%d+%d)", ...);
}

off and len are u_int32_t (in6_cksum.c:91). off + len is computed in unsigned 32-bit; values near 2^32 wrap to small numbers, the comparison then passes, and the intended "should never happen" panic is skipped. The mbuf walk (:150-156) then consumes the whole chain while off remains huge, exits with m == NULL, and :157-158

w = (u_int16_t *)(mtod(m, u_char *) + off);
mlen = m->m_len - off;

read m->m_data through the NULL pointer → low-page fault panic (uncontrolled, not the intended message). A wrapping len alone (with small off) instead drains the chain in the final loop and hits the panic("out of data") at :285-286 — also bypassing the intended first panic, same root cause.

Reachability analysis (why Info)

Caller matrix (every in6_cksum() call site), pass-2 verified:

The clamp that anchors everything: ip6_input.c:628-638 — packets shorter than 40 + ip6_plen are dropped; longer ones are trimmed to exactly 40 + ip6_plen. Largest possible len is therefore ~64 KiB — a wrap needs off + len ≥ 2^32, impossible from any caller.

The mirror wrap_demo.c (built with the guest toolchain, run.log) shows the bypass arithmetic exactly; a KLD calling in6_cksum(m, nxt, 0xFFFFFFFF, 41) would convert this into a guest panic, but that only demonstrates what the mirror already proves and would dirty an otherwise clean guest for an Info finding — deliberately not done.

Fix

Overflow-safe re-statement of the same invariant (see fix.diff):

if (len > (u_int32_t)m->m_pkthdr.len ||
    off > (u_int32_t)m->m_pkthdr.len - len)
        panic(...);

fix.diff authored against the read-only sys/ tree; not applied, not kernel- built (Info finding — fix validation not applicable; fix_status: not_testable).

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.