Incorrect totlen update after packet truncation produces wrong xmitOctets statistics
Summary
When BPF filter returns snaplen(len) less than packet length code truncates mbuf via m_adj correctly but updates totlen with totlen-=len instead of totlen=len. FreeBSD upstream uses totlen=len. Result dhip->stats.xmitOctets records (orig_totlen-len) instead of actual forwarded length (len). No memory-safety only incorrect statistics accounting. [VERIFIED pass2: source-confirmed totlen minus-equals-len stats bug; one-line fix compile-validated]
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-2596 · 8 files| File | Type | Description | Size | |
|---|---|---|---|---|
| VERDICT.md | — | 1.3 KB | ↓ raw | |
| README.md | — | 232 B | ↓ raw | |
| build.sh | — | 85 B | view raw | |
| run.sh | — | 49 B | view raw | |
| env.txt | — | 314 B | view raw | |
| manifest.json | — | 603 B | view raw | |
| verdict.json | — | 2.0 KB | view raw | |
| fix.diff | — | 301 B | view raw |
DF-2596 evidence pack
- finding: sys/netgraph/bpf/ng_bpf.c (415-417)
- verdict: reproduced (certain) - see VERDICT.md
- source-only confirmation (no runtime PoC)
- reproduce: build.sh / run.sh
- fix.diff: present, git-apply-able
DF-2596 - Verification Verdict
Status: reproduced Impact: none (hardening) Confidence: certain
Mechanism
After truncating the mbuf to the filter return value (m_adj(m, -(totlen - len))), the code updates totlen -= len instead of totlen = len, so totlen becomes original_len - truncated_len, which equals the new length only when original == 2*len.
Verdict
source-confirmed (no runtime PoC; deterministic code trace of the cited path:line in the read-only sys/ tree). Stats-only corruption: the subsequent xmit hook accounting adds the wrong octet count (e.g. 100-byte packet truncated to 30 reports 70 instead of 30). Arithmetic is deterministic; no runtime rig built (netgraph plumbing for a stats-only wrong number was not worth the guest cycle budget in this Info batch).
Threat / reachability
Latent code defect; see VERDICT.md.
Privilege escalation assessment
n/a (hardening)
Fix
totlen = len;
Kernel references
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.
Fix verification
not_testablefix.diff compile-validated in the batch combined kernel build (all 37 diffs of this batch applied to in-guest /usr/src; make -j6 nativekernel KERNCONF=X86_64_GENERIC, see batch build log referenced in VERDICT.md); no behavior A/B performed for this Info-tier item; behavior A/B intentionally skipped for Info tier
batch combined kernel build log (see findings/poc/_batch41 note in VERDICT.md)
Confirmed kernel references
Detail
Exploit chain
no escalation path (Info-tier hardening; see VERDICT.md)
Evidence (decisive lines)
VERDICT.md mechanism/verdict sections; fix.diff
PoC changes
none (source-only confirmation for this Info-tier item)
Verified recommended fix
totlen = len;
Verdict
source-confirmed (no runtime PoC; deterministic code trace of the cited path:line in the read-only sys/ tree). Stats-only corruption: the subsequent xmit hook accounting adds the wrong octet count (e.g. 100-byte packet truncated to 30 reports 70 instead of 30). Arithmetic is deterministic; no runtime rig built (netgraph plumbing for a stats-only wrong number was not worth the guest cycle budget in this Info batch).
No comments yet.