kern/85258: changing promisc mode on nic can lead to kernel panic

Pawel Malachowski pawmal-posting at freebsd.lublin.pl
Tue Aug 23 21:30:17 GMT 2005


>Number:         85258
>Category:       kern
>Synopsis:       changing promisc mode on nic can lead to kernel panic
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Aug 23 21:30:15 GMT 2005
>Closed-Date:
>Last-Modified:
>Originator:     Pawe³ Ma³achowski
>Release:        FreeBSD 5.3/5.4
>Organization:
osaczeni
>Environment:
FreeBSD 5.3 and 5.4-RELEASE, GENERIC kernel with DEVICE_POLLING, vlan, ipfw,
dummynet and ipl (IP Filter) loaded from modules (in sync with system).

>Description:
Router boxes have fxp NICs (usually renamed to wan0 and lan0, lan1 by
ifconfig rename), polling enabled, HZ set to 1000 and do a lot of NAT
(ipnat) and dummynet pipes processing.

Frequent changing of promisc flag on interface (for example, by using tcpdump
utility) will result in kernel panic (this was noticed by Krzysztof Cholewa).

This can be reproduced by executing ifconfig promisc and -promisc in endless
loop.

Backtrace is always the same. Please look at mtu value.

It also seems that turning polling off at least lowers the risk of panic.

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0xc
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc0646fab
stack pointer           = 0x10:0xc7aafb64
frame pointer           = 0x10:0xc7aafb88
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 28 (swi5: clock sio)
trap number             = 12
panic: page fault
Uptime: 2h56m54s

(kgdb) bt
#0  doadump () at pcpu.h:159
#1  0xc0614daa in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:410
#2  0xc0615040 in panic (fmt=0xc080b849 "%s")
    at /usr/src/sys/kern/kern_shutdown.c:566
#3  0xc07c3e14 in trap_fatal (frame=0xc7aafb24, eva=12)
    at /usr/src/sys/i386/i386/trap.c:817
#4  0xc07c3b7f in trap_pfault (frame=0xc7aafb24, usermode=0, eva=12)
    at /usr/src/sys/i386/i386/trap.c:735
#5  0xc07c37c1 in trap (frame=
      {tf_fs = -1051328488, tf_es = 16, tf_ds = -945160176, tf_edi = -1050883500, tf_esi = 16329, tf_ebp = -945095800, tf_isp = -945095856, tf_ebx = -1050883584, tf_edx = 0, tf_ecx = -1052078048, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1067159637, tf_cs = 8, tf_eflags = 66054, tf_esp = 0, tf_ss = -1065904684})
    at /usr/src/sys/i386/i386/trap.c:425
#6  0xc07b397a in calltrap () at /usr/src/sys/i386/i386/exception.s:140
#7  0xc1560018 in ?? ()
#8  0x00000010 in ?? ()
#9  0xc7aa0010 in ?? ()
#10 0xc15cca54 in ?? ()
#11 0x00003fc9 in ?? ()
#12 0xc7aafb88 in ?? ()
#13 0xc7aafb50 in ?? ()
#14 0xc15cca00 in ?? ()
#15 0x00000000 in ?? ()
#16 0xc14a9020 in ?? ()
#17 0x00000000 in ?? ()
#18 0x0000000c in ?? ()
#19 0x00000000 in ?? ()
#20 0xc0646fab in m_copym (m=0x0, off0=16380, len=16360, wait=1)
    at /usr/src/sys/kern/uipc_mbuf.c:386
#21 0xc069e7a4 in ip_fragment (ip=0xc14a9020, m_frag=0xc7aafc40, mtu=-1050883584,
    if_hwassist_flags=0, sw_csum=1) at /usr/src/sys/netinet/ip_output.c:967
#22 0xc069e450 in ip_output (m=0xc1bd7700, opt=0xc14a9020, ro=0xc7aafc0c, flags=0,
    imo=0x0, inp=0x0) at /usr/src/sys/netinet/ip_output.c:796
#23 0xc09f1ff5 in ?? ()
#24 0xc1bd7700 in ?? ()
#25 0x00000000 in ?? ()
#26 0xc7aafc0c in ?? ()
#27 0x00000000 in ?? ()
#28 0x00000000 in ?? ()
#29 0x00000000 in ?? ()
#30 0xc1bae000 in ?? ()
#31 0x00000033 in ?? ()
#32 0x00000000 in ?? ()
#33 0xc7aafca0 in ?? ()
#34 0xc09f231d in ?? ()
#35 0xc169ce00 in ?? ()
#36 0x0007d000 in ?? ()
#37 0x00000000 in ?? ()
#38 0x00000000 in ?? ()
#39 0x0007d000 in ?? ()
#40 0x00000000 in ?? ()
#41 0x00000001 in ?? ()
#42 0x00000000 in ?? ()
#43 0x00000001 in ?? ()
#44 0xc169ce00 in ?? ()
#45 0xc1bae000 in ?? ()
#46 0xc09f65c0 in ?? ()
#47 0x00000000 in ?? ()
#48 0xc7aafcc8 in ?? ()
#49 0xc09f2877 in ?? ()
#50 0xc1bae000 in ?? ()
#51 0xc09f65c0 in ?? ()
#52 0xc09f65e0 in ?? ()
#53 0xc09f65d0 in ?? ()
#54 0xb0c2eb80 in ?? ()
#55 0x00000006 in ?? ()
#56 0x00000000 in ?? ()
#57 0xc09f27a4 in ?? ()
#58 0xc7aafcf4 in ?? ()
#59 0xc0620bf6 in softclock (dummy=0xc169ce00)
    at /usr/src/sys/kern/kern_timeout.c:279
Previous frame inner to this frame (corrupt stack?)


>How-To-Repeat:
Execute the following shell script with proper interface as argument.
In my environment this will lead to panic within few minutes (up to
few hours). Sucessfully tested on three routers.


#!/bin/sh
while [ 1 ]
do
 date
 ifconfig $1 promisc
 sleep 5
 ifconfig $1 -promisc
 sleep 5
done


>Fix:
Unknown.

>Release-Note:
>Audit-Trail:
>Unformatted:


More information about the freebsd-bugs mailing list