src/sys/netpfil, branch main

pf(4) fix NULL pointer dereference in outbound packet path.

2026-07-23T11:27:36Z

Outbound packet which matches rule with source limiter attached, for example: source limiter "crash" id 1 entries 10000 limit 1000 pass out from any to any source limiter "crash" keep state triggers a NULL pointer dereference. The issue was kindly reported and initial version of fix submitted by SecBuddyF, Tencent KeenLab. The submitted diff fixed the issue for failing look up by destination address in outbound packet. dlg@ also pointed out the change should be further improved so NULL pointer dereference is avoided when rule uses nat-to/rdr-to option. OK dlg@ Obtained from: OpenBSD, sashan , f0f215c11e Sponsored by: Rubicon Communications, LLC ("Netgate")

pf: include direction in fragment key

2026-07-23T11:27:30Z

pf(4) currently ignores fragment direction (in vs. out) in pf_frnode_compare() function. Issue noticed and reported by Frank Denis OK @bluhm Obtained from: OpenBSD, sashan , eaa2c80721 Sponsored by: Rubicon Communications, LLC ("Netgate")

pf: fix a crash on sendfile()

2026-07-08T07:23:17Z

The network layer must not pass unmapped (M_EXTPG) mbufs to if_output() of network interfaces without IFCAP_MEXTPG. pf should convert these mbufs by mb_unmapped_to_ext() for such interfaces but it didn't. The problem had occurred on sendfile because sendfile system call uses unmapped mbufs for the file data. Reported by: feld Reviewed by: kp, glebius Differential Revision: https://reviews.freebsd.org/D58021

pf: revert netlink commands back to enum

2026-07-06T19:41:25Z

Revert pf_nl.h part of 017690e50913 and use new libsysdecode build glue that parses enums. Reviewed by: kp, glebius Differential Revision: https://reviews.freebsd.org/D57866

pflog: run VNET_SYSUNINIT in SI_SUB_PROTO_FIREWALL

2026-06-30T13:57:41Z

Suggested by: pouria, glebius Sponsored by: Rubicon Communications, LLC ("Netgate")

pflog: create bpf tapping points without ifnet(9)

2026-06-28T13:59:35Z

Just as was done for ipfw's log device stop creating entire struct ifnet's for pflog devices. Create only a bpf_t. This does mean we lose the create/destroy infrastructure provided by the clone interface. Rather than implement this ourselves we allow users to configure the number of pflog interfaces using the net.pflog.if_count sysctl. We default to 8 devices, but allow up to 256. The /etc/rc.d/pflog script will create extra devices as required. While it was possible to rename pflog devices pfctl expected the pflogX name, so it's safe to assume users never did this. Requested by: glebius Reviewed by: glebius Sponsored by: Rubicon Communications, LLC ("Netgate") Differential Revision: https://reviews.freebsd.org/D57851

pflog: remove unused argument from pflogattach()

2026-06-25T19:34:05Z

ipfw/nat64: Fix type confusion panic when using wrong NAT64 instance type

2026-06-22T22:15:36Z

Add etlv type validation to ipfw_nat64clat() and ipfw_nat64stl() to verify that the retrieved instance is actually a nat64clat instance before use. All NAT64 instance types share the same srvstate[] array but have different struct layouts. Without type validation, using the wrong instance type with a handler causes type confusion and kernel panic. Signed-off-by: Teddy Engel PR: 292023 Reviewed by: pouria Pull Request: https://github.com/freebsd/freebsd-src/pull/2259

pf: free match rules after exiting critical section

2026-06-10T21:50:27Z

This fixes a panic reported on armv7: sys/netpfil/pf/counters:match_block -> panic: free: called with spinlock or critical section held [...] vpanic() at vpanic pc = 0xc0321b5c lr = 0xc02f7b5c (free+0x140) sp = 0xc8c858bc fp = 0xc8c858e0 r4 = 0xe2fad648 r5 = 0xe402ce78 r6 = 0xc8c859e8 r7 = 0x0000001c r8 = 0xc8c858b4 r9 = 0xc0321b5c r10 = 0xc8c858bc free() at free+0x140 pc = 0xc02f7b5c lr = 0xe2f4f920 ($a+0x5f8) sp = 0xc8c858e8 fp = 0xc8c85930 r4 = 0xe402ce68 r5 = 0xc8c8599c r6 = 0xffffffff r10 = 0x0000001c [...] KDB: enter: panic Consequently, this fixes armv7 CI: https://ci.freebsd.org/job/FreeBSD-main-armv7-test/2287/consoleText Fixes: 6353f5d9a5c6f194bb014b8785a57f5314e8c652 Reviewed by: kp MFC after: 3 days

ipfw nat: Add assertion that mbuf is not a chain

2026-06-08T20:47:24Z

Discarding m_free's return value will result in an mbuf leak if the mbuf was in a chain. In general we should use m_freem if the mbuf may be in a chain, or assert that the return was NULL. There will not be a chain here due to m_megapullup, so add an assert. Reviewed by: ae Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D57479