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?

EdoFede

Sorry for my late answer.

I have 16GB of RAM on this machine (of which 5% is used on average), so I never worried about swap.

I now see that there are swap partitions on both disks (8GB each)

[2.8.0-RELEASE][root@fw.coppy.lan]/root: gpart show
=>       40  125045344  ada0  GPT  (60G)
         40     532480     1  efi  (260M)
     532520       1024     2  freebsd-boot  (512K)
     533544        984        - free -  (492K)
     534528   16777216     3  freebsd-swap  (8.0G)
   17311744  107732992     4  freebsd-zfs  (51G)
  125044736        648        - free -  (324K)

=>       40  125045344  ada1  GPT  (60G)
         40     532480     1  efi  (260M)
     532520       1024     2  freebsd-boot  (512K)
     533544        984        - free -  (492K)
     534528   16777216     3  freebsd-swap  (8.0G)
   17311744  107732992     4  freebsd-zfs  (51G)
  125044736        648        - free -  (324K)

=>        1  120164351  da0  MBR  (57G)
          1         31       - free -  (16K)
         32  120164320    1  fat32lba  (57G)

they are present in fstab

[2.8.0-RELEASE][root@fw.coppy.lan]/root: cat /etc/fstab
# Device		Mountpoint	FStype	Options		Dump	Pass#
/dev/gpt/efiboot0		/boot/efi	msdosfs	rw		2	2
/dev/ada0p3		none	swap	sw		0	0
/dev/ada1p3		none	swap	sw		0	0

but swapinfo doesn't show any swap area in use:

[2.8.0-RELEASE][root@fw.coppy.lan]/root: swapinfo -h
Device              Size     Used    Avail Capacity

It's an installation made some time ago (I think on 2.7.0) with ZFS, but never touched at the disk level.

Sure, I can try with 2.8.1 (I just noticed that it has been released).
Or do you prefer that I activate the swap and try to get a full core dump first?

Thanks!

stephenw10

Try 2.8.1 first if you can.

You are probably hitting this preventing the SWAP being enabled: https://redmine.pfsense.org/issues/16232
Unfortunately that fix didn't make it into 2.8.1 but you can apply that patch there. Or manually make the one character change!
That should give you the expected 16G of swap which will be enough for any core file.