Summary

check_forward treats cmd->arg3 (the forward destination count) as the bound for indexing an array of struct sockaddr_in at sa += i, but the kernel never validates that arg3 matches the number of sockaddr_in entries actually embedded in the instruction (derivable from F_LEN(cmd)). A malformed rule installed via a crafted setsockopt(IP_FW_ADD) sockopt causes sa[krandom()%arg3] to read up to ~3 KB past the instruction into adjacent kernel heap; the leaked 16 bytes are then used as the packet's forward destination — a kernel-memory-to-network info leak.

Root cause

ip_fw3_basic.c:213: sa = &((ipfw_insn_sa *)cmd)->sa; — pointer to the first embedded sockaddr_in. Line 216: if(cmd->arg3 > 1) gates multi-destination selection. Lines 218/220/223 produce i in [0, cmd->arg3). Line 225: sa += i; advances by i*16 bytes. Line 227: *sin = *sa; copies 16 bytes. If arg3 exceeds the actual embedded count, the read is OOB.

The rule installer ip_fw3_ctl_add_rule (ip_fw3.c:950-969) validates only the outer sockopt byte size and never validates cmd->arg3 against F_LEN(cmd).

Threat model

• Privilege: root / SYSCAP_NONET_RAW to install the malformed rule.
• Impact: every subsequent packet matching the rule (including remote/ unprivileged traffic) triggers a 16-byte kernel heap read at a randomized offset up to ~4 KB past the rule slab. The read bytes become the forward destination IP/port → kernel-memory-to-network info leak.

Recommended fix

Derive the real destination count from the instruction length instead of trusting cmd->arg3: ndest = (F_LEN(cmd) - F_INSN_SIZE(ipfw_insn)) / F_INSN_SIZE(struct sockaddr_in);

References

• sys/net/ipfw3_basic/ip_fw3_basic.c:213-227 — the vulnerable path.
• sys/net/ipfw3_basic/ip_fw3.c:950-969 — rule installer with no semantic validation of arg3.

Timeline

• 2026-07-02 Discovered during automated DragonFlyBSD kernel security audit.
• 2026-07-02 Reported to DragonFlyBSD security contact (pending).