Subject: kern/29014: wi driver bug: panic in wi_start
To: None <kern-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: Pavel Cahyna <pavel.cahyna@st.mff.cuni.cz>
List: netbsd-bugs
Date: 01/19/2005 21:38:00
>Number: 29014
>Category: kern
>Synopsis: wi driver bug: panic in wi_start
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Jan 19 21:38:00 +0000 2005
>Originator: Pavel Cahyna
>Release: NetBSD 2.0_BETA i386
>Organization:
>Environment:
System: NetBSD 2.0_BETA (PCAP) #4: Tue Jul 13 10:49:01 CEST 2004
pavel@pc.localdomain:/home/pavel/kompilace/jadra/compile/PCAP
>Description:
The wi_start function contains some dubious pointer arithmetic:
--- cut here ---
IF_DEQUEUE(&ic->ic_pwrsaveq, m0);
wh = mtod(m0, struct ieee80211_frame *);
llc = (struct llc *) (wh + 1);
m_copydata(m0, 4, ETHER_ADDR_LEN * 2,
(caddr_t)&frmhdr.wi_ehdr);
---> frmhdr.wi_ehdr.ether_type = llc->llc_snap.ether_type;
--- cut here ---
the pointer obtained from mtod is incremented without ensuring that the result will point
to a valid memory (e.g. by calling m_pullup or m_pulldown) and then dereferenced.
The arrow points to the line where I actually saw a panic on a machine with wi1 in hostap mode:
wi_start(c0945034,c001,0,c0b25c34,c0945000) at netbsd:wi_start+0x5ea
ieee80211_input(c0945034,c0b25c00,c0b68a00,9,9c63937a) at netbsd:ieee80211_input+0x1ea
wi_rx_intr(c0945000,0,c0838e60,c04d74c9,c0838e6c) at netbsd:wi_rx_intr+0x524
wi_intr(c0945000,0,ba6f0010,30,5f10010) at netbsd:wi_intr+0x231
Xintr_legacy3() at netbsd:Xintr_legacy3+0xa4
--- interrupt ---
cpu_switch(c077fb40,0,0,c0100d30,c0915d80) at netbsd:cpu_switch+0x9f
ltsleep(c077f9a0,4,c06af41e,0,0) at netbsd:ltsleep+0x35f
uvm_scheduler(c077f980,0,c07885fc,c069510c,0) at netbsd:uvm_scheduler+0x74
main(0,0,0,0,0) at netbsd:main+0x69b
backtrace from gdb is:
(gdb) bt
#0 0x00000001 in ?? ()
#1 0xc03ead7f in cpu_reboot (howto=8622080, bootstr=0x0)
at /usr/src/sys/arch/i386/i386/machdep.c:743
#2 0xc0322919 in db_reboot_cmd (addr=1, have_addr=0, count=-1068651870,
modif=0xc0838824 "�\213y�;\210\203�\001")
at /usr/src/sys/ddb/db_command.c:689
#3 0xc032245f in db_command (last_cmdp=0xc0722b84, cmd_table=0x0)
at /usr/src/sys/ddb/db_command.c:464
#4 0xc0322172 in db_command_loop () at /usr/src/sys/ddb/db_command.c:255
#5 0xc032523c in db_trap (type=0, code=0) at /usr/src/sys/ddb/db_trap.c:101
#6 0xc03e84e2 in kdb_trap (type=6, code=0, regs=0x0)
at /usr/src/sys/arch/i386/i386/db_interface.c:225
#7 0xc03f4fab in trap (frame=0xc0838a78)
at /usr/src/sys/arch/i386/i386/trap.c:284
#8 0xc0102d89 in calltrap ()
#9 0xc03c3bde in ieee80211_input (ifp=0xc0945034, m=0xc0b25c00, ni=0x7,
rssi=9, rstamp=2623771514) at /usr/src/sys/net80211/ieee80211_input.c:241
#10 0xc02191cc in wi_rx_intr (sc=0xc0945000) at /usr/src/sys/dev/ic/wi.c:1507
#11 0xc02171dd in wi_intr (arg=0xc0945000) at /usr/src/sys/dev/ic/wi.c:550
#12 0xc0101400 in Xintr_legacy3 ()
See also http://mail-index.netbsd.org/tech-net/2004/08/07/0001.html and following.
(Message-ID: <20040807160428.GA32338@artax.karlin.mff.cun
>How-To-Repeat:
Having a NetBSD machine with wi acting as an access point with a client in power-saving mode
triggers this panic sometimes.
>Fix:
I provided a patch in the thread referenced above, but I am not sure about its correctness.
A review by somebody who actually understands this code is necessary.