NetBSD Problem Report #29014

From pavel.cahyna@st.mff.cuni.cz  Wed Jan 19 21:37:24 2005
Return-Path: <pavel.cahyna@st.mff.cuni.cz>
Received: from mail.casablanca.cz (mail.casablanca.cz [82.208.31.182])
	by narn.netbsd.org (Postfix) with ESMTP id 8E27F63B844
	for <gnats-bugs@gnats.netbsd.org>; Wed, 19 Jan 2005 21:37:23 +0000 (UTC)
Message-Id: <1106171164.0@pc.martani.n2.repy.czf>
Date: Wed, 19 Jan 2005 21:46:04 -0000
From: "Pavel Cahyna" <pavel.cahyna@st.mff.cuni.cz>
To: "gnats bugs" <gnats-bugs@netbsd.org>
Cc: David Young <dyoung@pobox.com>
Subject: wi driver bug: panic in wi_start
X-Send-Pr-Version: gtk-send-pr 0.4 
X-GNATS-Notify:

>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.

Home	PR Database Search