Date: Thu, 18 Dec 2025 08:44:46 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 291764] Kernel panic in FreeBSD 14.3 with PF when using state limits and tagging Message-ID: <bug-291764-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291764 Bug ID: 291764 Summary: Kernel panic in FreeBSD 14.3 with PF when using state limits and tagging Product: Base System Version: 14.3-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: igor.arabesc.pavlov@gmail.com System: - FreeBSD 14.3-RELEASE releng/14.3-n271432-8c9ce319fef7 GENERIC - Reproducible both on custom-built kernel/world and stock GENERIC kernel - Firewall: PF I am experiencing a reproducible kernel panic in FreeBSD 14.3 when PF rules use state limits (keep state (max ...)) and packet tagging. The panic occurs shortly after PF rules are loaded and traffic starts flowing. Initially I suspected ALTQ queues, but the issue reproduces on a clean GENERIC kernel without ALTQ enabled. I normally run a customized FreeBSD system with kernel and world built from sources. The system had been stable for a long time. I started experimenting with PF traffic shaping and: - enabled ALTQ in the kernel, - added PF queues, - added state limits and tagging rules (features I had not used before). After applying the PF configuration, the kernel panicked within a few seconds. After reboot, the system would panic repeatedly a few seconds after services started. I was advised on the FreeBSD forum to try reproducing the issue on a stock GENERIC kernel. I tested with the official prebuilt kernel: https://download.freebsd.org/ftp/releases/amd64/14.3-RELEASE/kernel.txz Booted with GENERIC kernel. Verified that my usual PF configuration works correctly. Modified PF rules to add only state limits and tagging (no ALTQ, no queues). The GENERIC kernel also panics within a few seconds after loading the modified PF rules. This suggests ALTQ is not required to trigger the bug. I noticed that the time to panic appears to depend on traffic patterns: - When active torrent traffic is present, the kernel usually panics within a few seconds. - If torrent traffic is stopped or absent, the kernel either does not panic at all or remains stable for a significantly longer time. This suggests the issue may be triggered or accelerated by a high rate of state creation or specific traffic patterns typical for torrent workloads. Panic / Call stack (typical): Fatal trap 12: page fault while in kernel mode cpuid = 6; apic id = 06 fault virtual address = 0x20 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff8304a873 stack pointer = 0x28:0xfffffe001b1d6690 frame pointer = 0x28:0xfffffe001b1d66f0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (swi1: netisr 6) rdi: fffffe001b1d6bd8 rsi: 000000000000d422 rdx: 0000000000000014 rcx: 0000000000000000 r8: 0000000000000000 r9: fffff80097f25800 rax: 0000000000006291 rbx: 0000000000000002 rbp: fffffe001b1d66f0 r10: 00000000ede0282f r11: 0000000000006291 r12: 0000000000000014 r13: fffff8029809d800 r14: 0000000000000000 r15: fffffe001b1d6bc0 trap number = 12 Timeout initializing vt_vga panic: page fault cpuid = 6 time = 1765952616 KDB: stack backtrace: #0 0xffffffff80ba8f1d at kdb_backtrace+0x5d #1 0xffffffff80b5aa11 at vpanic+0x161 #2 0xffffffff80b5a8a3 at panic+0x43 #3 0xffffffff8104db7a at trap_pfault+0x3da #4 0xffffffff81023d88 at calltrap+0x8 #5 0xffffffff83043403 at pf_test_rule+0x2493 #6 0xffffffff8303e084 at pf_test+0x1584 #7 0xffffffff830621f7 at pf_check_in+0x27 #8 0xffffffff80ca4c58 at pfil_mbuf_in+0x38 #9 0xffffffff80d1df3b at ip_input+0x38b #10 0xffffffff80ca2458 at swi_net+0x128 #11 0xffffffff80b17069 at ithread_loop+0x239 #12 0xffffffff80b13641 at fork_exit+0x81 #13 0xffffffff81024dee at fork_trampoline+0xe The fault consistently occurs inside pf_test_rule(). The following PF rules are stable: ... nat on $wan_if inet proto {tcp udp} from $transmission_ip to any -> ($wan_if) static-port rdr on $wan_if inet proto {tcp udp} from any to ($wan_if) port $transmission_port -> $transmission_ip ... pass in quick on $wan_if proto {tcp udp} from any to $transmission_ip port $transmission_port keep state label "Transmission in" pass out quick on $wan_if proto {tcp udp} from ($wan_if) to any keep state label "Transmission out" ... After adding tagging and state limits, the kernel starts panicking: ... nat on $wan_if inet proto {tcp udp} from $transmission_ip to any tag Torrent -> ($wan_if) static-port rdr on $wan_if inet proto {tcp udp} from any to ($wan_if) port $transmission_port -> $transmission_ip ... pass in quick on $wan_if proto {tcp udp} from any to $transmission_ip port $transmission_port keep state (max 300) label "Transmission in" pass out quick on $wan_if proto {tcp udp} from ($wan_if) to any tagged Torrent keep state (max 500) label "Transmission out" ... The crash happens very quickly after PF rules are loaded. Disabling PF or reverting these directives avoids the panic. I am not attaching kernel crash dumps publicly, but I can provide them privately upon request. -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-291764-227>