Kernel Panic with ICMPv6 echo request when IPv6 disabled

[norg]

I had quite a journey when I wanted to debug why my OPNSense appliance suddenly rebooted several times. So in the crash log I saw this:

Code: [Select]

Fatal trap 12: page fault while in kernel mode
cpuid = 3; apic id = 03
fault virtual address = 0x54
fault code = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff80f5e626
stack pointer         = 0x28:0xfffffe00004c2140
frame pointer         = 0x28:0xfffffe00004c2190
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 (swi4: clock (0))
trap number = 12
panic: page fault
cpuid = 3
time = 1603188380
__HardenedBSD_version = 1200059 __FreeBSD_version = 1201000
version = FreeBSD 12.1-RELEASE-p10-HBSD #0  517e44a00df(stable/20.7)-dirty: Mon Sep 21 16:21:17 CEST 2020
    root@sensey64:/usr/obj/usr/src/amd64.amd64/sys/SMP
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00004c1df0
vpanic() at vpanic+0x1a2/frame 0xfffffe00004c1e40
panic() at panic+0x43/frame 0xfffffe00004c1ea0
trap_fatal() at trap_fatal+0x39c/frame 0xfffffe00004c1f00
trap_pfault() at trap_pfault+0x49/frame 0xfffffe00004c1f60
trap() at trap+0x29f/frame 0xfffffe00004c2070
calltrap() at calltrap+0x8/frame 0xfffffe00004c2070
--- trap 0xc, rip = 0xffffffff80f5e626, rsp = 0xfffffe00004c2140, rbp = 0xfffffe00004c2190 ---
in6_setscope() at in6_setscope+0xa6/frame 0xfffffe00004c2190
ip6_forward() at ip6_forward+0x359/frame 0xfffffe00004c22e0
pf_test6() at pf_test6+0x1c82/frame 0xfffffe00004c2470
pf_check6_out() at pf_check6_out+0x3f/frame 0xfffffe00004c24a0
pfil_run_hooks() at pfil_run_hooks+0x87/frame 0xfffffe00004c2530
ip6_output() at ip6_output+0x1a06/frame 0xfffffe00004c27c0
icmp6_reflect() at icmp6_reflect+0x2f0/frame 0xfffffe00004c2870
icmp6_error() at icmp6_error+0x4aa/frame 0xfffffe00004c28c0
nd6_llinfo_timer() at nd6_llinfo_timer+0x340/frame 0xfffffe00004c2940
softclock_call_cc() at softclock_call_cc+0x143/frame 0xfffffe00004c29f0
softclock() at softclock+0x79/frame 0xfffffe00004c2a10
ithread_loop() at ithread_loop+0x1d4/frame 0xfffffe00004c2a70
fork_exit() at fork_exit+0x83/frame 0xfffffe00004c2ab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00004c2ab0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
panic.txt0600001213743533234  7140 ustarrootwheelpage faultversion.txt06000022713743533234  7623 ustarrootwheelFreeBSD 12.1-RELEASE-p10-HBSD #0  517e44a00df(stable/20.7)-dirty: Mon Sep 21 16:21:17 CEST 2020
    root@sensey64:/usr/obj/usr/src/amd64.amd64/sys/SMP

OPNsense (c) 2014-2020 Deciso B.V.

So the kernel panic was related to IPv6. In my case I didn't use IPv6 due to another bug in 20.7 but I still receive those packets on my VDSL WAN interface. The reason for that is, that I have a static IPv6 network assigned to me, a /64 for the WAN side and a /54 for my own usage. So my provider did forward those packets still to my VDSL and through my PPPoE connection since it's static, my own and the provider doesn't know that I disabled IPv6 DHCP on my PPPoE connection.

So the fix was to enable the IPv6 on WAN side (the /64) but I could still keep it disabled on LAN side (the /56) to prevent another bug.

But nevertheless I would argue that this should be fixed in the FreeBSD Kernel so it doesn't trigger a panic, just ignoring/dropping those packets.

So my question would be, is this something that needs to be adressed by the OPNSense folks or rather on FreeBSD side or even HardenedBSD side?
So I would like to have some guidance where to report which details.
While it might be a corner case (static IPv6 but disabled on PPPoE) it was really hard to figure it out.