Bug 275474 - if_gre: kernel panic when doing ifconfig deletetunnel on interface with udpencap
Summary: if_gre: kernel panic when doing ifconfig deletetunnel on interface with udpencap
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 14.0-RELEASE
Hardware: Any Any
: --- Affects Only Me
Assignee: Andrey V. Elsukov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-12-01 18:47 UTC by Philipp Wuensche
Modified: 2023-12-14 13:01 UTC (History)
3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Philipp Wuensche 2023-12-01 18:47:26 UTC 
I'm using udpencap of the if_gre interface and stumbled across a bug where when decommissioning a if_gre interface with the ifconfig deletetunnel (or -tunnel) command panics the system.

I reduced the panic to running these commands on any vanilla 13.2 or 14.0-RELEASE:

ifconfig gre1 create
ifconfig gre2 create
ifconfig gre1 tunnel 127.0.0.1 127.0.0.3 udpencap
ifconfig gre2 tunnel 127.0.0.1 127.0.0.2 udpencap
ifconfig gre1 -udpencap
ifconfig gre2 -udpencap
ifconfig gre1 deletetunnel
ifconfig gre2 deletetunnel

I can also trigger the same when running theses commands three times in a row:

ifconfig gre1 create
ifconfig gre2 create
ifconfig gre1 tunnel 127.0.0.1 127.0.0.3 udpencap
ifconfig gre2 tunnel 127.0.0.1 127.0.0.2 udpencap
ifconfig gre1 deletetunnel
ifconfig gre2 deletetunnel

Doing the tunnel command without the udpencap stops the crashing.
 
I can get a crashdump and this is what I get:

# lldb /boot/kernel/kernel -c /var/crash/vmcore.0
(lldb) target create "/boot/kernel/kernel" --core "/var/crash/vmcore.0"
Core file '/var/crash/vmcore.0' (x86_64) was loaded.
(lldb) bt
* thread #1, name = '(pid 69501) ifconfig (crashed)'
  * frame #0: 0xffffffff80c066ae kernel`doadump + 46
    frame #1: 0xffffffff80c0648a kernel`kern_reboot + 1082
    frame #2: 0xffffffff80c0692e kernel`vpanic + 446
    frame #3: 0xffffffff80c06763 kernel`panic + 67
    frame #4: 0xffffffff810b1fa7 kernel`trap_fatal + 903
    frame #5: 0xffffffff810b1fff kernel`trap_pfault + 79
    frame #6: 0xffffffff81088fe8 kernel`calltrap + 8
    frame #7: 0xfffff800237c63b0
    frame #8: 0xffffffff80ca674d kernel`soclose + 205
    frame #9: 0xffffffff82320fa1
    frame #10: 0xffffffff8232086f
    frame #11: 0xffffffff80d1d557 kernel`ifhwioctl + 2023
    frame #12: 0xffffffff80d1f218 kernel`ifioctl + 1912
    frame #13: 0xffffffff80c749fd kernel`kern_ioctl + 621
    frame #14: 0xffffffff80c746e0 kernel`sys_ioctl + 256
    frame #15: 0xffffffff810b289c kernel`amd64_syscall + 268
    frame #16: 0xffffffff810898fb kernel`fast_syscall_common + 248


Any ideas?
Comment 1 Philipp Wuensche 2023-12-01 21:33:26 UTC 
Can reproduce this on 12.4-RELEASE and 13.2-RELEASE aarch64 bootonly iso, also on amd64 13.2-RELEASE install.
Comment 2 cryx-freebsd 2023-12-02 12:10:28 UTC 
Some users which were trying to reproduce this for me on their systems had it not panic when they typed in the commands one after the other but when putting them into a script and executing them quickly the system paniced.

Works also in a VNET jail when the host has if_gre kernel module loaded.