rule->set byte unvalidated at install (expected 0..31): 1 << f->set undefined behavior and broken set-disable/move semantics for sets >= 32
Summary
ipfw_check_ioc_rule() never validates ioc_rule->set even though the set subsystem is defined for 0..31 (ipfw_ctl_alter rejects set args >= 31). At classification time ipfw_chk computes ipfw_set_disable & (1 << f->set) - for set in 32..255 this is undefined shift behavior; on x86 the shift is masked so the rule silently aliases into set (set & 31), and set-move/swap/compare operations compare the raw byte, so an administrator can never correctly enable/disable/move such a rule via the set API. Root-installed rules only; no memory unsafety on x86; policy-confusion footgun + C UB. Fix: reject set >= IPFW_DEFAULT_SET at install. [VERIFIED pass2: reproduced - set 40 and 200 rules install then set disable 8 freezes them via shift aliasing, set move rejects; fix compile-validated]
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-3261 Β· 10 files| File | Type | Description | Size | |
|---|---|---|---|---|
| addset.c | β | 4.1 KB | view raw | |
| run.log | β | 1008 B | view raw | |
| README.md | β | 672 B | β raw | |
| VERDICT.md | β | 2.2 KB | β raw | |
| build.sh | β | 181 B | view raw | |
| run.sh | β | 210 B | view raw | |
| manifest.json | β | 728 B | view raw | |
| verdict.json | β | 1.9 KB | view raw | |
| fix.diff | β | 660 B | view raw | |
| env.txt | β | 272 B | view raw |
DF-3261 -- verification pack
Finding: ipfw rule set byte unvalidated; 1 << set UB and broken set administration
Status: reproduced / impact denial_of_service / confidence certain
What was run
guest: cc -O -o addset addset.c (raw IP_FW_ADD with exact ipfw_ioc_rule layout)
How to reproduce
guest: kldload ipfw + staged allow rule; addset 40 1000; addset 200 1001; addset 8 1002; ping; ipfw set disable 8; ping; ipfw show
Expected
sets 40/200 install; set disable 8 freezes all three rules counters; set move 40 rejected
See VERDICT.md for the full narrative and verdict.json for the persisted machine verdict. Artifacts: addset.c, run.log.
DF-3261 verification
Kernel: DragonFly dfbsd 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64
Bottom line
ipfw_check_ioc_rule never validates the set byte: rules installed via the same IP_FW_ADD sockopt the CLI uses with set=40 and set=200 are accepted (set subsystem is defined 0..31). ipfw -S list shows them as set 40 and set 200; ipfw set disable 8 instantly stops ALL THREE test rules (sets 40, 200 and the legal 8) from counting packets - on x86 the 1 << 40 and 1 << 200 classification-time shifts mask to 1 << 8 (ip_fw2.c:3601 UB) - and ipfw set move 40 to 0 refuses with invalid source number 40, so the administrator can never correctly administer such rules through the set API. Root-installed policy confusion plus C undefined behavior; no memory unsafety on x86.
Kernel references
Exploit chain
(none: availability/correctness finding; no privilege chain)
Fix
reject set >= 31 at install; combined fixed kernel: addset 40 is refused with invalid set while legal sets still install
See fix.diff in this directory (git-apply-able against the read-only sys/ tree; applied only inside the disposable verification guest).
Reproduction
build: guest: cc -O -o addset addset.c (raw IP_FW_ADD with exact ipfw_ioc_rule layout)
run: guest: kldload ipfw + staged allow rule; addset 40 1000; addset 200 1001; addset 8 1002; ping; ipfw set disable 8; ping; ipfw show
expected: sets 40/200 install; set disable 8 freezes all three rules counters; set move 40 rejected
Notes on the PoC (what changed vs the finding sketch)
three layout fixes: cmd words start at byte 60 (15 header words, cmd[1] embedded), total = 4*(15+cmd_len), and the opcode values are the enum ordinals (O_VIA=19, O_COUNT=46), not header line numbers
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_testableConfirmed kernel references
Detail
Evidence (decisive lines)
run.log: installation output, the three counters frozen by set disable 8 and resumed by set enable 8, set move rejection
PoC changes
three layout fixes: cmd words start at byte 60 (15 header words, cmd[1] embedded), total = 4*(15+cmd_len), and the opcode values are the enum ordinals (O_VIA=19, O_COUNT=46), not header line numbers
Verified recommended fix
reject set >= 31 at install; combined fixed kernel: addset 40 is refused with invalid set while legal sets still install
Verdict
ipfw_check_ioc_rule never validates the set byte: rules installed via the same IP_FW_ADD sockopt the CLI uses with set=40 and set=200 are accepted (set subsystem is defined 0..31). ipfw -S list shows them as set 40 and set 200; ipfw set disable 8 instantly stops ALL THREE test rules (sets 40, 200 and the legal 8) from counting packets - on x86 the 1 << 40 and 1 << 200 classification-time shifts mask to 1 << 8 (ip_fw2.c:3601 UB) - and ipfw set move 40 to 0 refuses with invalid source number 40, so the administrator can never correctly administer such rules through the set API. Root-installed policy confusion plus C undefined behavior; no memory unsafety on x86.
No comments yet.