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 #1421 (new defect)

Opened 14 years ago

Last modified 14 years ago

madwifi 100% reproducible kernel panic associating a VAP with a wrong wep key

Reported by: Cdtdaddy <d.guerri@caspur.it> Assigned to:
Priority: major Milestone:
Component: madwifi: driver Version: trunk
Keywords: Cc:
Patch is attached: 0 Pending:

Description

My setup:

- Latest openWRT from svn (2523), standard configuration (non preemtible kernel) - miniPCI Atheros AR5213A-00 and Atheros AR5213A-001 - on PC Engines WRAP.1E v1.11

On the WRAP i execute the following commands:

wlanconfig ath create wlandev wifi0 wlanmode ap
iwconfig ath0 essid testSSID enc aabbccddeeffaabbccddeeff00 channel 4 mode master
ifconfig ath0 up

On the client (MacOsX, Linux, Windows, ...) i try to associate with a wrong wep key. For instance on my osx command line i do the following:

<threepwood:davide># /System/Library/PrivateFrameworks/Apple80211.framework/Resources/airport -s
28 Infrastructure networks found:
                            SSID Security     Ch Sig Vr  ID IE BSSID             WPA (Auth[]), (Cipher[])                
                  Alice-08953902 WPA PSK      11 -66 -1   0  0 00:03:6f:90:b9:ed   1 (2,0,0,0), ( 2(TKIP),0,0,0)
                  Alice-87115966 WPA PSK      11 -62 -1   0  0 00:03:6f:92:04:85   1 (2,0,0,0), ( 2(TKIP),0,0,0)
                        testSSID WEP           4 -11 -1   0  0 06:0b:6b:4c:ee:9f   0 (0,0,0,0), (0,0,0,0)
                         USR5463               6 -63 -1   0  0 00:14:c1:2b:f9:58   0 (0,0,0,0), (0,0,0,0)

[...]

<threepwood:davide># /System/Library/PrivateFrameworks/Apple80211.framework/Resources/airport -AtestSSID
password: <something like "blablabla">
<threepwood:davide># /System/Library/PrivateFrameworks/Apple80211.framework/Resources/airport -AtestSSID
password: <again, something like "blablabla">

After this on the WRAP i get:

root@OpenWrt:/# BUG: unable to handle kernel NULL pointer dereference at virtual address 0000010c
 printing eip:
c88f03d4
*pde = 00000000
Oops: 0000 [#1]
Modules linked in: ne2k_pci 8390 ath_pci wlan_xauth wlan_wep wlan_tkip wlan_ccmp wlan_acl ath_rate_minstrel ath_hal(P) wlan_scan_sta wlan_scan_ap wlan ipt
_TTL ipt_ttl ipt_TOS ipt_time ipt_tos xt_MARK xt_mark xt_mac xt_length ipt_ECN ipt_ecn xt_DSCP xt_dscp xt_CLASSIFY imq ipt_IMQ ipt_ipp2p xt_NOTRACK iptabl
e_raw xt_portscan xt_DELUDE xt_CHAOS xt_string ipt_recent xt_pkttype ipt_owner ipt_LOG xt_connbytes xt_helper xt_CONNMARK xt_connmark arptable_filter arpt
_mangle arp_tables tun ppp_async ppp_generic slhc crc_ccitt natsemi
CPU:    0
EIP:    0060:[<c88f03d4>]    Tainted: P       VLI
EFLAGS: 00010002   (2.6.22-rc5 #2)
eax: 00000000   ebx: c74d0000   ecx: 00000001   edx: 0000001f
esi: c74d016d   edi: 00000000   ebp: 00000202   esp: c02b5c30
ds: 007b   es: 007b   fs: 0000  gs: 0000  ss: 0068
Process swapper (pid: 0, ti=c02b4000 task=c0296280 task.ti=c02b4000)
Stack: c88f003c c0122f04 c029de70 0000000c 000000b0 c7587000 c0123f25 c754a380
       c74d0000 c74d0000 00000000 c7b58380 c88f0613 c12686e8 c754a380 c7587000
       000d0002 000000b0 c88e984e 00000001 c7587800 c7b58380 00000001 c74d016d
Call Trace:
 [<c88f003c>] <0> [<c0122f04>] <0> [<c0123f25>] <0> [<c88f0613>] <0> [<c88e984e>] <0> [<c88ed7ce>] <0> [<c88ddbd7>] <0> [<c0122f04>] <0> [<c0123f25>] <0>
[<c88d6a1d>] <0> [<c88eb4ac>] <0> [<c88d5310>] <0> [<c88ef91d>] <0> [<c88dd029>] <0> [<c011d53a>] <0> [<c010f10c>] <0> [<c010f074>] <0> [<c010f0d6>] <0> [
<c0103b8f>] <0> [<c0250a25>] <0> [<c0102513>] <0> [<c01012eb>] <0> [<c02c0000>] <0> [<c0101312>] <0> [<c0100b55>] <0> [<c02b6a03>] <0> [<c02b63e0>] <0> ==
=====================
Code: 44 24 28 83 7c 24 28 20 0f 85 37 ff ff ff 55 9d 83 c4 30 5b 5e 5f 5d c3 55 57 56 53 83 ec 20 89 d6 0f b6 52 05 83 e2 1f 9c 5d fa <8b> bc 90 90 00 00
 00 e9 87 00 00 00 85 db 74 06 8b 47 04 89 43
EIP: [<c88f03d4>]  SS:ESP 0068:c02b5c30
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 3 seconds..PC Engines WRAP.1C/1D/1E v1.11
640 KB Base Memory
130048 KB Extended Memory
[...]

openWRT kamikaze r2523 comes with madwifi r2420-20070602, but i've tried r2518-20070626 with the same results.

Attachments

OSXvsMadWiFi-20070629.pcap (17.2 kB) - added by Cdtdaddy <d.guerri@caspur.it> on 06/29/07 11:52:49.
pcap dump of 802.11 frames that produce the kernel panic

Change History

06/27/07 04:35:48 changed by mickflemm

Please don't open so many tickets again, use the preview button instead ;-)

Thanx for your feedback

06/29/07 00:16:59 changed by Cdtdaddy <d.guerri@caspur.it>

I've compiled a clean openWRT kamikaze r7765 kernel with CONFIG_KALLSYMS. Here is the kernel panic for madwifi r2420-20070602

BUG: unable to handle kernel NULL pointer dereference at virtual address 0000010c
 printing eip:
c88a0450
*pde = 00000000
Oops: 0000 [#1]
Modules linked in: ne2k_pci 8390 ath_pci wlan_xauth wlan_wep wlan_tkip wlan_ccmp wlan_acl ath_rate_minstrel ath_hal(P) wlan_scan_sta wlan_scan_ap wlan ppp_async ppp_generic slhc crc_ccitt natsemi
CPU:    0
EIP:    0060:[<c88a0450>]    Tainted: P       VLI
EFLAGS: 00010002   (2.6.22-rc6 #3)

EIP is at ieee80211_remove_wds_addr+0x10/0xd3 [wlan]
eax: 00000000   ebx: c7970800   ecx: 00000001   edx: 0000001f
esi: 00000000   edi: 00000202   ebp: c7970969   esp: c7b07d08
ds: 007b   es: 007b   fs: 0000  gs: 0000  ss: 0068

Process dropbearkey (pid: 1575, ti=c7b06000 task=c1286a90 task.ti=c7b06000)
Stack: c7970800 00000000 c7fe0001 c7fea380 c88a05fa 00000000 00000000 c114c01c 
       c7fea380 c12683e8 c7fea380 c114c000 c799d380 000000b0 c889bf8e c799d380 
       c799d380 c7fe0001 c7970800 c889e7ca 000d0002 c797f380 c797f000 c797f380 
Call Trace:
 [<c88a05fa>] ieee80211_node_leave+0x22/0x2d3 [wlan]
 [<c889bf8e>] ieee80211_check_mic+0x157/0x17e [wlan]
 [<c889e7ca>] ieee80211_recv_mgmt+0x125e/0x2626 [wlan]
 [<c011b784>] update_wall_time+0x4f4/0x64d
 [<c01f37d2>] dev_hard_start_xmit+0x18e/0x1ed
 [<c0108bba>] __activate_task+0x1c/0x28
 [<c0118966>] autoremove_wake_function+0x15/0x35
 [<c0108a8f>] __wake_up_common+0x31/0x4f
 [<c88d0012>] ath_detach+0xc1b/0x1d2c [ath_pci]
 [<c889d387>] ieee80211_input+0xd65/0xf4a [wlan]
 [<c01ef6a6>] __alloc_skb+0x51/0xfd
 [<c01efa4e>] skb_copy+0xb9/0xc1
 [<c889fbe3>] ieee80211_input_all+0x51/0x82 [wlan]
 [<c88d3e3e>] ath_attach+0x2d1b/0x31a7 [ath_pci]
 [<c01f4daf>] net_rx_action+0x52/0xd0

 [<c010f0cc>] __do_softirq+0x35/0x75
 [<c010f12e>] do_softirq+0x22/0x26
 [<c0103bdf>] do_IRQ+0x55/0x6a
 [<c0102523>] common_interrupt+0x23/0x30
 =======================
Code: 8b 33 8b 04 24 39 43 10 75 f0 eb bb 45 83 fd 20 75 a8 57 9d 5e 5f 5b 5e 5f 5d c3 55 57 56 53 89 d5 0f b6 52 05 83 e2 1f 9c 5f fa <8b> 9c 90 90 00 00 00 eb 37 85 f6 74 06 8b 43 04 89 46 04 8b 43 
EIP: [<c88a0450>] ieee80211_remove_wds_addr+0x10/0xd3 [wlan] SS:ESP 0068:c7b07d08
Kernel panic - not syncing: Fatal exception in interrupt


06/29/07 00:44:25 changed by Cdtdaddy <d.guerri@caspur.it>

I've found the problem:

ieee80211_remove_wds_addr is called by ieee80211_node_leave with nt = NULL.

Skipping the call for null values of ni->ni_table avoids the kernel panic. Although madwifi seems to stable i fear it's only an hack ...

However, diff follows

diff -p madwifi-ng-r2420-20070602/net80211/ieee80211_node.c ieee80211_node.c 
*** madwifi-ng-r2420-20070602/net80211/ieee80211_node.c 2007-05-30 03:41:18.000000000 +0200
--- ieee80211_node.c    2007-06-29 00:38:30.000000000 +0200
*************** ieee80211_node_leave(struct ieee80211_no
*** 1850,1861 ****
        /* From this point onwards we can no longer find the node,
         * so no more references are generated
         */
!       ieee80211_remove_wds_addr(nt, ni->ni_macaddr);
!       ieee80211_del_wds_node(nt, ni);
!       IEEE80211_NODE_TABLE_LOCK_IRQ(nt);
!       _node_table_leave(nt, ni);
!       IEEE80211_NODE_TABLE_UNLOCK_IRQ(nt);
! 
        /*
         * If node wasn't previously associated all
         * we need to do is reclaim the reference.
--- 1850,1862 ----
        /* From this point onwards we can no longer find the node,
         * so no more references are generated
         */
!         if (nt) {
!               ieee80211_remove_wds_addr(nt, ni->ni_macaddr);
!               ieee80211_del_wds_node(nt, ni);
!               IEEE80211_NODE_TABLE_LOCK_IRQ(nt);
!               _node_table_leave(nt, ni);
!               IEEE80211_NODE_TABLE_UNLOCK_IRQ(nt);
!       }
        /*
         * If node wasn't previously associated all
         * we need to do is reclaim the reference.

06/29/07 11:48:50 changed by Cdtdaddy <d.guerri@caspur.it>

Sorry from my previous statement about reproducibility of the bug with any OS as a client. I'm only able to reproduce the kernel panic with an *osx* sta.
I don't know why the wds code is called, but i'm still able to reproduce this bug with my osx.
Other atheros cards and a DWL-G122 802.11g rev. B1 (ralink) on linux work as expected.

I'm going to attach a pcap dump of 802.11 frames that produce the kernel panic.

06/29/07 11:52:49 changed by Cdtdaddy <d.guerri@caspur.it>

  • attachment OSXvsMadWiFi-20070629.pcap added.

pcap dump of 802.11 frames that produce the kernel panic

07/01/07 00:37:30 changed by Cdtdaddy <d.guerri@caspur.it>

patch 309-micfail_detect of openwrt kamikaze svn r7813 contains a workaround for the issue.

07/01/07 13:28:16 changed by mentor

Hmmm... ieee80211_node_leave is racing?

07/01/07 23:34:12 changed by Cdtdaddy <d.guerri@caspur.it>

maybe ieee80211_node_leave is called 2 times. However i can't (yet) figure out why that happens only with osx.