NetBSD Problem Report #26484

Received: (qmail 16691 invoked by uid 605); 30 Jul 2004 23:20:43 -0000
Message-Id: <200407302320.i6UNKYHZ006300@cobalt.plectere.com>
Date: Fri, 30 Jul 2004 16:20:34 -0700 (PDT)
From: paul@Plectere.com
Sender: gnats-bugs-owner@NetBSD.org
Reply-To: paul@Plectere.com
To: gnats-bugs@gnats.NetBSD.org
Subject: ifconfig/wiconfig can cause infinite recursion in ieee80211_end_scan
X-Send-Pr-Version: 3.95

>Number:         26484
>Category:       kern
>Synopsis:       wiconfig -D failures can cause a kernel panic due to stack to overflow
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jul 30 23:21:00 +0000 2004
>Closed-Date:    
>Last-Modified:  Sat Nov 12 16:53:30 +0000 2005
>Originator:     Paul Shupak
>Release:        NetBSD 2.0G
>Organization:

>Environment:


System: NetBSD cobalt 2.0G NetBSD 2.0G (COBALT-$Revision: 1.4 $) #576: Tue Jul 27 16:42:52 PDT 2004 root@svcs:/sys/arch/i386/compile/COBALT i386
Architecture: i386
Machine: i386
>Description:

	The function ieee80211_end_scan() can infinitely recurse (indirectly
through ieee80211_next_scan(), but the compiler merges the instances so the
intermediate function isn't visible in the stack dump).
	This causes a panic in some cases, a machine reboot in most cases
(e.g. a kernel double/triple-fault).
>How-To-Repeat:

	NOTE:  The problem may be in the driver, the HAL or the 802.11 layer,
I'm not sure.  But it is 100% repeatable with any 802.11a capable "ath"
(i.e. either a 5210 "a" only card, a 5211 "ab" card or 521[23] "ag" cards ).

First case:
	% ifconfig ath0 media auto
	% ifconfig ath0 mode 11a	# No bug for "b" or "g"
	% ifconfig ath0 down		# if "up", there is no bug!
	<CRTL><ALT><ESC>
	db> break ieee80211_end_scan
	db> c
	% wiconfig ath0 -D
	wiconfig: SIOCSWAVELAN: Invalid argument
	%
	db>

continue/watch until you tire or the machine reboots (a long time if you
only continue one recursion at a time).

Second case - Slightly different:
	% ifconfig ath0 media auto
	% ifconfig ath0 mode 11a
	% ifconfig ath0 down
	% ifconfig ath0 chan 36		# force an initial channel assignment
	<CRTL><ALT><ESC>
	db> break ieee80211_end_scan
	db> c
	% wiconfig ath0 -D
	wiconfig: SIOCSWAVELAN: Invalid argument
	%
	db>

continue/watch until you tire or the machine reboots or panics with
a double fault in ieee80211_end_scan() (about the 25th recursion,
when it panics, sometime more - even much more - 114 was the longest
panic I was willing to press return until, while counting).

	Also, notice that the "wiconfig" command completes with an error (the
message is "wiconfig: SIOCSWAVELAN: Invalid argument" and exits before
the panic or reboot occurs.  The problem seems to be related to the 802.11
state machine getting out of wack (hence, you must be "down" and "wiconfig"
then forces the interface "up", ...).

	In my environment all channels from 36 up to 64 are almost always
in use, the 5.8 channels are generally free but noisy, however disabling
(re. freeing some lower channels) the APs doesn't change the behavior
(even removing the antenna an substituting a terminator doesn't change
things).  I can generate a kernel dump at will, if desired.

>Fix:

	Not known (at least by me).  Probably a `better' method of dealing
with not finding an unused channel (rare in San Jose, near me) than starting
over (at least don't recurse indefinitely).
>Release-Note:
>Audit-Trail:
>Unformatted:
 	Userland as of today (problem has existed for a while).

Home	PR Database Search