⬢ DragonFlyBSD Kernel Audit
← triage · dashboard
DF-2582

Unbounded shift and missing masklen=0 guard in table_append_dispatch yield wrong mask (logic bug UB)

Summary

table_append_dispatch computes htonl(~((1<<(32-mlen))-1)) directly from user-supplied uint8_t masklen no clamp. mlen>32 UB negative shift x86 masks to 5 bits wrong mask. mlen==0 evaluates 1<<32 UB and unlike table_remove_dispatch (:215) append path lacks mlen? :0 guard so /0 stored as /32 firewall correctness bug. Logic/UB not memory corruption. [VERIFIED pass2: runtime reproduced as root - masklen 0 33 64 accepted with 33 stored as slash-1 so wrong mask live in the tree; mlen validation fix; adjacent finds - ipfw3_basic unload rn_flush NULL panic and inverted SHOW counter]

Discussion (0)

No comments yet.

PoC verification

Evidence pack

findings/poc/DF-2582 · 10 files
FileTypeDescriptionSize
VERDICT.md — 1.8 KB ↓ raw
README.md — 257 B ↓ raw
build.sh — 90 B view raw
run.sh — 159 B view raw
env.txt — 314 B view raw
manifest.json — 750 B view raw
verdict.json — 3.0 KB view raw
fix.diff — 894 B view raw
ipfw3_masklen.c — 2.4 KB view raw
run.log — 536 B view raw
README.md
↓ download raw

DF-2582 evidence pack

  • finding: sys/net/ipfw3_basic/ip_fw3_table.c (161-164)
  • verdict: reproduced (certain) - see VERDICT.md
  • runtime PoC: ipfw3_masklen.c
  • reproduce: build.sh / run.sh ; expected output in run.log
  • fix.diff: present, git-apply-able
VERDICT.md
↓ download raw

DF-2582 - Verification Verdict

Status: reproduced Impact: corruption Confidence: certain

Mechanism

table_append_dispatch computes mask = htonl(~((1 << (32 - mlen)) - 1)) from the user masklen with no validation. mlen==0 makes the shift count 32, mlen>32 makes it negative (both UB); on x86 the count masks to 5 bits so the stored mask is silently WRONG (33 -> /1, 64 -> /32, 0 -> /32).

Verdict

REPRODUCED as root on the stock guest (kldload ipfw3 + ipfw3_basic, firewall disabled during the test): APPEND accepts masklen 0, 33 and 64 (setsockopt rc=0 each). Behavioral proof in one table: empty table -> 1.2.3.4 not found; honest 10.1.2.0/24 -> 10.1.2.9 found / 10.9.9.9 not found; after appending 11.0.0.5/33 the entry is stored as 0.0.0.0/1, so 99.0.0.1 (top bit 0) now MATCHES the table while 200.1.1.1 does not - the bogus catch-all from the unbounded shift is live in the radix lookup tree the firewall datapath uses. Root-gated (raw socket).

Threat / reachability

Root-configured firewall tables silently match the wrong prefixes (a /33 rule behaves like a /1 catch-all); combined with rule logic this is rule-bypass/enabler territory, but only reachable by the firewall administrator.

Privilege escalation assessment

n/a (root-gated configuration path)

Fix

Validate mlen (reject >32, special-case 0 -> zero mask) before the shift.

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_testable

fix.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)
↓ fix.diffper-fix-DF-2582

Confirmed kernel references

Detail

Exploit chain

no escalation path: raw socket / ipfw3 config is root-gated (SYSCAP_NONET_RAW); wrong masks corrupt the firewall rule matching the admin configured

Evidence (decisive lines)

run.log: append masklen 0/33/64 all rc=0 (ACCEPTED); honest /24 -> 10.1.2.9 found, 10.9.9.9 not; after /33 append 99.0.0.1 FOUND while 200.1.1.1 NOT - the UB shift stored 0.0.0.0/1 live in the lookup tree

PoC changes

Rebuilt the seed entirely: DFly ipfw3 sockopt convention is setsockopt/getsockopt optname IP_FW_X with an ip_fw_x_header opcode prefix; the SHOW readback is dead on this kernel (walks depend on a counter that append increments only on rnh_addaddr FAILURE), so the proof uses IP_FW_TABLE_TEST lookups with a fresh table id and clean negative controls.

Verified recommended fix

Validate mlen (reject >32, special-case 0 -> zero mask) before the shift.

Verdict

REPRODUCED as root on the stock guest (kldload ipfw3 + ipfw3_basic, firewall disabled during the test): APPEND accepts masklen 0, 33 and 64 (setsockopt rc=0 each). Behavioral proof in one table: empty table -> 1.2.3.4 not found; honest 10.1.2.0/24 -> 10.1.2.9 found / 10.9.9.9 not found; after appending 11.0.0.5/33 the entry is stored as 0.0.0.0/1, so 99.0.0.1 (top bit 0) now MATCHES the table while 200.1.1.1 does not - the bogus catch-all from the unbounded shift is live in the radix lookup tree the firewall datapath uses. Root-gated (raw socket).