Kernel panic related to BGP and IPv6 after upgrading to 2.8.0

EdoFede

Hello!

I'm experiencing consistent kernel panics on my pfSense firewall, with 5 identical crashes over the past few weeks. All crashes follow the exact same pattern and appear to be related to BGP IPv6 operations.

Stack Trace Pattern

All crashes show identical stack traces:

ip6_output() at ip6_output+0xe20
tcp_default_output() at tcp_default_output+0x1eed  
tcp_usr_close() at tcp_usr_close+0x87
soclose() at soclose+0x125

Analysis (AI generated)

The kernel panic occurs consistently in the IPv6 output path when the BGP daemon attempts to close TCP connections. The NULL pointer dereference at address 0x0 suggests a bug in the kernel's IPv6 stack, specifically in the ip6_output() function.

This appears to be a critical kernel bug that affects system stability when BGP is configured with IPv6 sessions.

Crash timestamps

2025-09-04 12:04:35
2025-09-01 11:36:29
2025-08-26 23:52:51
2025-08-26 01:25:25
2025-08-25 03:18:02

I attach the full crash report.
pfSense crash report.txt

Has anyone else experienced similar crashes with BGP and IPv6 on pfSense 2.8.0? Is there a known fix or patch available for this issue?

Thanks.

Bye,
Edoardo

JonathanLee

@EdoFede do you have the crash dump file ?

stephenw10

It's linked in the post.

Backtrace:

db:1:pfs> bt
Tracing pid 15766 tid 101221 td 0xfffff80182988000
kdb_enter() at kdb_enter+0x33/frame 0xfffffe00d8ebd6c0
panic() at panic+0x43/frame 0xfffffe00d8ebd720
trap_fatal() at trap_fatal+0x40b/frame 0xfffffe00d8ebd780
trap_pfault() at trap_pfault+0x46/frame 0xfffffe00d8ebd7d0
calltrap() at calltrap+0x8/frame 0xfffffe00d8ebd7d0
--- trap 0xc, rip = 0xffffffff80f74ca0, rsp = 0xfffffe00d8ebd8a0, rbp = 0xfffffe00d8ebda70 ---
ip6_output() at ip6_output+0xe20/frame 0xfffffe00d8ebda70
tcp_default_output() at tcp_default_output+0x1eed/frame 0xfffffe00d8ebdc60
tcp_usr_close() at tcp_usr_close+0x87/frame 0xfffffe00d8ebdcb0
soclose() at soclose+0x125/frame 0xfffffe00d8ebdd10
_fdrop() at _fdrop+0x11/frame 0xfffffe00d8ebdd30
closef() at closef+0x24a/frame 0xfffffe00d8ebddc0
closefp_impl() at closefp_impl+0x58/frame 0xfffffe00d8ebde00
amd64_syscall() at amd64_syscall+0x115/frame 0xfffffe00d8ebdf30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe00d8ebdf30
--- syscall (6, FreeBSD ELF64, close), rip = 0x82b97a9ea, rsp = 0x8211f9b28, rbp = 0x8211f9b40 ---

Do the crashes all present an identical backtrace like that? Edit: Never mind I see they do!

stephenw10

Can you test in 2.8.1?
I'm not aware of anything that went in to specifically address this but it would be good to know it still happens there.

stephenw10

Beyond that we can try to get a full core dump from the panic if you have sufficiently large SWAP space to store it?