β¬’ DragonFlyBSD Kernel Audit
← triage Β· dashboard
DF-3261

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)

No comments yet.

PoC verification

Evidence pack

findings/poc/DF-3261 Β· 10 files
FileTypeDescriptionSize
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.

VERDICT.md
↓ download raw

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_testable
↓ fix.diffper-fix-DF-3261

Confirmed 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.