Bug 247746 - System reboots when attempting to name a network interface 'bridge'
Summary: System reboots when attempting to name a network interface 'bridge'
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 12.1-RELEASE
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-net (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-07-03 19:24 UTC by Markus Stoff
Modified: 2020-07-09 02:23 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Stoff 2020-07-03 19:24:03 UTC
Issuing the following command will reboot the system:

  # br=$(ifconfig bridge create)
  # ifconfig ${br} name bridge
Comment 1 Tom Jones freebsd_committer 2020-07-03 19:29:48 UTC
I am not able to reproduce this on stable or current:

FreeBSD freebsd-stable 12.1-STABLE FreeBSD 12.1-STABLE r362809 GENERIC  amd64 
FreeBSD freebsd-current 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r362198: Mon Jun 15 16:28:21 UTC 2020
Comment 2 Tom Jones freebsd_committer 2020-07-03 19:44:51 UTC
I am also not able to reproduce on 12.1-RELEASE
FreeBSD freebsd 12.1-RELEASE FreeBSD 12.1-RELEASE r354233 GENERIC  amd64

I can't reproduce in bhyve on current, stable or release. Could you provide more details of your system? There is probably some interaction with other components.
Comment 3 Kristof Provost freebsd_committer 2020-07-03 20:27:56 UTC
I can't be sure without a backtrace, but I suspect Markus has pf loaded. pf panics if there's an interface and a group with the same name.

See #218895. My position here is that that's a system bug, because the ability to have groups and interfaces with the same name was accidentally introduced when interface renaming was implemented.

The locking around interfaces, and lack of error handling paths for renames makes this tricky to fix.
Comment 4 Eugene Grosbein freebsd_committer 2020-07-03 20:33:24 UTC
(In reply to Kristof Provost from comment #3)

Would it be easy to implement prohibition of renaming interface to name of existing group if pf filtering hook is not NULL?
Comment 5 Kristof Provost freebsd_committer 2020-07-03 20:36:51 UTC
(In reply to Eugene Grosbein from comment #4)
Offhand I don't think so. I also wouldn't expect that to fix the problem, because it can also be triggered by first naming an interface foo and then creating a group foo.
Comment 6 Tom Jones freebsd_committer 2020-07-03 20:39:31 UTC
Loading pf did it.

root@freebsd-current:~ # kldload pf                                                                            
root@freebsd-current:~ # ifconfig bridge create                                                                
bridge0                                                                                                        
root@freebsd-current:~ # ifconfig bridge0 name bridge                                                          
                                                                                                               
Fatal double fault                                                                                             
rip 0xffffffff80c0b9dc rsp 0xfffffe00aafcb000 rbp 0xfffffe00aafcb020                                           
rax 0xfffff80003ba9140 rdx 0 rbx 0xfffff80005e9c700                                                            
rcx 0xfffff80003ccd700 rsi 0xfffff8000378c700 rdi 0                                                            
r8 0x100 r9 0xffffffff8190d980 r10 0xffffffff81d390e0                                                          
r11 0x1 r12 0 r13 0                                                                                            
r14 0xfffffe00aafce810 r15 0xfffff80005e9c800 rflags 0x10246                                                   
cs 0x20 ss 0x28 ds 0x3b es 0x3b fs 0x13 gs 0x1b                                                                
fsbase 0x800257920 gsbase 0xffffffff82213000 kgsbase 0                                                         
cpuid = 3; apic id = 03                                                                                        
panic: double fault                                                                                            
cpuid = 3                                                                                                      
time = 1593808620                                                                                              
KDB: stack backtrace:                                                                                          
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00217b5db0                                 
vpanic() at vpanic+0x182/frame 0xfffffe00217b5e00                                                              
panic() at panic+0x43/frame 0xfffffe00217b5e60                                                                 
dblfault_handler() at dblfault_handler+0x1d1/frame 0xfffffe00217b5f20                                          
Xdblfault() at Xdblfault+0xd7/frame 0xfffffe00217b5f20                                                         
--- trap 0x17, rip = 0xffffffff80c0b9dc, rsp = 0xfffffe00aafcb000, rbp = 0xfffffe00aafcb020 ---                
in_epoch_verbose() at in_epoch_verbose+0xc/frame 0xfffffe00aafcb020                                            
pfi_kif_update() at pfi_kif_update+0x20/frame 0xfffffe00aafcb080                                               
pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafcb0e0                                              
pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafcb140                                              
pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafcb1a0                                              
pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafcb200                                              
pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafcb260    
                                          
... lots more ...

pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafce3e0
pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafce440
pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafce4a0
pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafce500
pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafce560
pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafce5c0
pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafce620
pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafce680
pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafce6e0
pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafce740
pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafce7a0
pfi_kif_update() at pfi_kif_update+0x27c/frame 0xfffffe00aafce800
pfi_attach_ifnet_event() at pfi_attach_ifnet_event+0xd6/frame 0xfffffe00aafce850
ifhwioctl() at ifhwioctl+0x10db/frame 0xfffffe00aafce8d0
ifioctl() at ifioctl+0x3ac/frame 0xfffffe00aafce9a0
kern_ioctl() at kern_ioctl+0x27b/frame 0xfffffe00aafcea00
sys_ioctl() at sys_ioctl+0x127/frame 0xfffffe00aafcead0
amd64_syscall() at amd64_syscall+0x140/frame 0xfffffe00aafcebf0
fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe00aafcebf0
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x800495e8a, rsp = 0x7fffffffe278, rbp = 0x7fffffffe290 ---
db>
Comment 7 Eugene Grosbein freebsd_committer 2020-07-03 22:30:54 UTC
Seems to be infinite recursion with kernel stack overflow leading to double fault.

Should be easy to fix for someone familiar with the pf code. Adding glebius@ to CC: in case he likes to take a look.
Comment 8 Markus Stoff 2020-07-04 07:42:31 UTC
(In reply to Kristof Provost from comment #3)

You are right Kristof, I'm using pf.