Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #1475 (closed defect: fixed)

Opened 12 years ago

Last modified 12 years ago

Client changing to restricted authentication causes kernel panic

Reported by: proski Assigned to: mentor
Priority: blocker Milestone: version 0.9.5
Component: madwifi: 802.11 stack Version: trunk
Keywords: DoS WEP Cc:
Patch is attached: 0 Pending:

Description

This looks like a remote DoS.

The AP is not using encryption. The client has a 40-bit WEP key set and uses open authentication. Then the client changes the algorithm to restricted and reconnects. MadWifi panics in interrupt.

The client is at76_usb. MadWifi is running on current Linux (wireless-dev git, 2.6.23-rc1) on x86_64.

Attachments

ath-panic (3.6 kB) - added by proski on 08/01/07 09:02:31.
Console log of the panic

Change History

08/01/07 09:02:31 changed by proski

  • attachment ath-panic added.

Console log of the panic

08/02/07 02:33:21 changed by proski

I can reproduce the problem on i386. But I can only reproduce it on trunk, not on the 0.9.3 branch. All that is necessary is to try shared key authentication. For some reason, it's required that at76_usb is run on the client (it can be downloaded by git from http://git.80211libre.org/at76_usb.git). I could not trigger the bug by spectrum_cs or MadWifi.

Initial debugging shows that the nt argument to ieee80211_remove_wds_addr() is NULL, and it's called by ieee80211_node_leave(), which is in turn called by ieee80211_auth_shared(). The later is missing in the stack trace for some reason.

But I would prefer that we wait with the 0.9.3.2 a little bit more until it's clear that 0.9.3 doesn't have this bug.

08/02/07 02:58:04 changed by proski

  • owner set to mentor.
  • milestone changed from version 0.9.3 to version 0.9.4.

It's the first "goto bad" in ieee80211_auth_shared() that is followed. It's the case when the client attempts shared key authentication, but privacy is disabled on the AP.

This "goto bad" is not hit when other clients are used. Apparently, they don't attempt shared key authentication with an AP without the privacy bit set.

ieee80211_node_leave() after "bad:" is present in the trunk, but not in the 0.9.3 branch, so I guess 0.9.3 is safe.

It appeared in ieee80211_node_leave() in r2357 (Merge ng-refcount to trunk). Adjusting the owner and the milestone accordingly.

08/02/07 04:49:37 changed by mentor

  • priority changed from critical to blocker.

08/09/07 02:46:27 changed by mentor

08/14/07 16:07:03 changed by mentor

  • status changed from new to closed.
  • resolution set to fixed.

02/11/08 06:21:42 changed by mrenzmann

  • milestone changed from version 0.9.4 to version 0.9.5.