Project

General

Profile

Bug #11285

Kernel crash on ALTQ-enabled wg interfaces

Added by Viktor Gurov about 1 month ago. Updated 9 days ago.

Status:
New
Priority:
Low
Assignee:
Category:
WireGuard
Target version:
Start date:
01/22/2021
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.5.0
Affected Architecture:

Description

If you create a traffic shaper queue on the assigned wg* interface,
any WireGuard manipulation (add peer / delete instance etc.) crashes the kernel:

Fatal trap 18: integer divide fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer    = 0x20:0xffffffff80e9b445
stack pointer            = 0x28:0xfffffe001d0f46f0
frame pointer            = 0x28:0xfffffe001d0f4730
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        = 83075 (ifconfig)
trap number        = 18
panic: integer divide fault
cpuid = 0
time = 1611313941
KDB: enter: panic
panic.txt0600002414002531425  7130 ustarrootwheelinteger divide faultversion.txt0600006214002531425  7525 ustarrootwheelFreeBSD 12.2-STABLE 738c68d5bed(devel-12) pfSense

Shaper:

<shaper>
                <queue>
                        <interface>opt1</interface>
                        <name>opt1</name>
                        <scheduler>CODELQ</scheduler>
                        <bandwidth>10</bandwidth>
                        <bandwidthtype>Mb</bandwidthtype>
                        <enabled>on</enabled>
                </queue>
                <queue>
                        <interface>opt3</interface>
                        <name>opt3</name>
                        <scheduler>CBQ</scheduler>
                        <bandwidth>10</bandwidth>
                        <bandwidthtype>Mb</bandwidthtype>
                        <enabled>on</enabled>
                        <queue>
                                <interface>opt3</interface>
                                <priority>1</priority>
                                <name>q1</name>
                                <bandwidth>5</bandwidth>
                                <bandwidthtype>Mb</bandwidthtype>
                                <enabled>on</enabled>
                                <default>default</default>
                        </queue>
                </queue>
        </shaper>

pf rules:

# grep wg /tmp/rules.debug 
WG0 = "{ wg0 }" 
WireGuard = "{ wg }" 
GWWG0_WGV4 = " route-to ( wg0 10.2.2.2 ) " 
 altq on wg0 cbq bandwidth 10Mb queue {  q1  } 
queue q1 on wg0 bandwidth 5Mb priority 1 cbq (  default  )  
nat on $WG0 inet6 from <tonatsubnets> to any port 500 -> (wg0)  static-port
nat on $WG0 inet6 from <tonatsubnets> to any -> (wg0) port 1024:65535 
pass out  route-to ( wg0 10.2.2.2 ) from 10.2.2.2 to !10.2.2.0/24 tracker 1000008012 keep state allow-opts label "let out anything from firewall host itself" 
pass  on {  vtnet1  vtnet0  vtnet2  wg0  enc0  openvpn  } inet proto tcp  from any to any tracker 1608041165 flags S/SA keep state  label "USER_RULE" 
pass  in  quick  on $WG0 reply-to ( wg0 10.2.2.2 ) inet proto tcp  from any to any tracker 1611315819 flags S/SA keep state  queue (q1)  label "USER_RULE" 

textdump.tar.0 (86 KB) textdump.tar.0 Viktor Gurov, 01/22/2021 05:53 AM
info (1).0 (396 Bytes) info (1).0 Viktor Gurov, 01/22/2021 05:53 AM

Related issues

Related to Todo #11280: Add WireGuard to ALTQ listNew2021-01-21

History

#1 Updated by Viktor Gurov about 1 month ago

  • Subject changed from Kerne crashl on ALTQ-enabled wg interfaces to Kernel crash on ALTQ-enabled wg interfaces

#2 Updated by Jim Pingle about 1 month ago

  • Related to Todo #11280: Add WireGuard to ALTQ list added

#3 Updated by Jim Pingle about 1 month ago

  • Assignee set to Peter Grehan
  • Priority changed from High to Low
  • Target version set to CE-Next

Moving ahead, no time to address this one for now. Reverted the change allowing ALTQ to be used with WireGuard for now.

#4 Updated by Viktor Gurov 11 days ago

seems related to #11470

#5 Updated by Jim Pingle 9 days ago

That doesn't look like the same issue, the backtrace is a quite a bit different despite both mentioning CBQ. They could be related, but they aren't close enough that I'd call them the same yet.

Also available in: Atom PDF