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

Opened 15 years ago

Last modified 15 years ago

ieee80211_input.c: dereferencing NULL pointer

Reported by: gregory smith <> Assigned to:
Priority: major Milestone:
Component: madwifi: other Version: trunk
Keywords: ieee80211_input ieee80211com NULL Cc:
Patch is attached: 0 Pending:


Hi developers,

I've been seeing kernel panics in the madwifi driver while switching modes on my Atheros 5212 NIC. It is very easy to reproduce: bring the card up in ad-hoc, let it associate to a cell, and then put it into master:

# wlanconfig ath0 destroy
# wlanconfig ath0 create wlandev wifi0 wlanmode adhoc
# ifconfig ath0 netmask up
(wait until it associates...)

# wlanconfig ath0 destroy
# wlanconfig ath0 create wlandev wifi0 wlanmode master
# ifconfig ath0 netmask up
(insert kernel crash here)

Although the source of the problem seems to differ, this behavior is common across /all/ versions that I've tried (0.9.1, 0.9.2, 0.9.3, svn). The ksymoops output for the SVN version follows below.

I tracked down the problem to ieee80211_input(), where ic (an ieee80211com struct pointer, copied from ni->ni_vap->iv_ic) is the culprit NULL pointer.

I don't understand the failure semantics of this function well enough to simply suggest/apply a fix. Could someone with more experience look into this problem or give me a suggestion for a temporary solution?


Unable to handle kernel NULL pointer dereference at virtual address 0000004c
*pde = 00000000
Oops: 0000 [#1]
CPU:    0
EIP:    0060:[<de88dfee>]    Tainted: P      VLI
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00210246   (2.6.16-skas3-v8.2 #8)
eax: 00000000   ebx: dc939260   ecx: 00000000   edx: dc86cd00
esi: 00000000   edi: dca32020   ebp: dd0c2000   esp: c0351ed8
ds: 007b   es: 007b   ss: 0068
Stack: <0>5000007b 00000000 00000000 dcdc3180 dcdc2260 dc000000 dca32020 de85b025
       dcde8000 dcdc3180 00000000 ff3bff34 dd3f8660 dcdc2260 dd564660 de848c94
       00200246 dd3f8660 de848cb9 0000017f 2a5959be 00000000 dd0c2000 c037b068
Call Trace:
 [<de85b025>] zz067d0c47+0x15/0x5c [ath_hal]
 [<de848c94>] ath_intr+0x93e/0xa6b [ath_pci]
 [<de848cb9>] ath_intr+0x963/0xa6b [ath_pci]
 [<de84813c>] ath_rx_tasklet+0x4cb/0x6e5 [ath_pci]
 [<c0117aab>] tasklet_action+0x37/0x58
 [<c0117a03>] __do_softirq+0x34/0x7f
 [<c0117a70>] do_softirq+0x22/0x26
 [<c0117b31>] irq_exit+0x25/0x30
 [<c010434f>] do_IRQ+0x1e/0x24
 [<c0102dba>] common_interrupt+0x1a/0x20
 [<c0101c07>] default_idle+0x2b/0x53
 [<c0101c6a>] cpu_idle+0x3b/0x56
 [<c03525c1>] start_kernel+0x228/0x22a
Code: c4 14 ff 83 c0 00 00 00 c6 44 24 16 ff e9 c7 12 00 00 8a 57 01 8a 4c 24 03 8b 74 24 04 80 e2 03 80 e1 0c 88 54 24 15 88 4c 24 16 <80> 7e 4c 00 0f 88 41 03 00 00 83 f8 06 0f 87 a0 12 00 00 ff 24

>>EIP; de88dfee <pg0+1e4f6fee/3fc67400>   <=====

>>ebx; dc939260 <pg0+1c5a2260/3fc67400>
>>edx; dc86cd00 <pg0+1c4d5d00/3fc67400>
>>edi; dca32020 <pg0+1c69b020/3fc67400>
>>ebp; dd0c2000 <pg0+1cd2b000/3fc67400>
>>esp; c0351ed8 <init_thread_union+1ed8/2000>

Trace; de85b025 <pg0+1e4c4025/3fc67400>
Trace; de848c94 <pg0+1e4b1c94/3fc67400>
Trace; de848cb9 <pg0+1e4b1cb9/3fc67400>
Trace; de84813c <pg0+1e4b113c/3fc67400>
Trace; c0117aab <tasklet_action+37/58>
Trace; c0117a03 <__do_softirq+34/7f>
Trace; c0117a70 <do_softirq+22/26>
Trace; c0117b31 <irq_exit+25/30>
Trace; c010434f <do_IRQ+1e/24>
Trace; c0102dba <common_interrupt+1a/20>
Trace; c0101c07 <default_idle+2b/53>
Trace; c0101c6a <cpu_idle+3b/56>
Trace; c03525c1 <start_kernel+228/22a>

This architecture has variable length instructions, decoding before eip
is unreliable, take these instructions with a pinch of salt.

Code;  de88dfc3 <pg0+1e4f6fc3/3fc67400>
00000000 <_EIP>:
Code;  de88dfc3 <pg0+1e4f6fc3/3fc67400>
   0:   c4 14 ff                  les    (%edi,%edi,8),%edx
Code;  de88dfc6 <pg0+1e4f6fc6/3fc67400>
   3:   83 c0 00                  add    $0x0,%eax
Code;  de88dfc9 <pg0+1e4f6fc9/3fc67400>
   6:   00 00                     add    %al,(%eax)
Code;  de88dfcb <pg0+1e4f6fcb/3fc67400>
   8:   c6 44 24 16 ff            movb   $0xff,0x16(%esp)
Code;  de88dfd0 <pg0+1e4f6fd0/3fc67400>
   d:   e9 c7 12 00 00            jmp    12d9 <_EIP+0x12d9>
Code;  de88dfd5 <pg0+1e4f6fd5/3fc67400>
  12:   8a 57 01                  mov    0x1(%edi),%dl
Code;  de88dfd8 <pg0+1e4f6fd8/3fc67400>
  15:   8a 4c 24 03               mov    0x3(%esp),%cl
Code;  de88dfdc <pg0+1e4f6fdc/3fc67400>
  19:   8b 74 24 04               mov    0x4(%esp),%esi
Code;  de88dfe0 <pg0+1e4f6fe0/3fc67400>
  1d:   80 e2 03                  and    $0x3,%dl
Code;  de88dfe3 <pg0+1e4f6fe3/3fc67400>
  20:   80 e1 0c                  and    $0xc,%cl
Code;  de88dfe6 <pg0+1e4f6fe6/3fc67400>
  23:   88 54 24 15               mov    %dl,0x15(%esp)
Code;  de88dfea <pg0+1e4f6fea/3fc67400>
  27:   88 4c 24 16               mov    %cl,0x16(%esp)

This decode from eip onwards should be reliable

Code;  de88dfee <pg0+1e4f6fee/3fc67400>
00000000 <_EIP>:
Code;  de88dfee <pg0+1e4f6fee/3fc67400>   <=====
   0:   80 7e 4c 00               cmpb   $0x0,0x4c(%esi)   <=====
Code;  de88dff2 <pg0+1e4f6ff2/3fc67400>
   4:   0f 88 41 03 00 00         js     34b <_EIP+0x34b>
Code;  de88dff8 <pg0+1e4f6ff8/3fc67400>
   a:   83 f8 06                  cmp    $0x6,%eax
Code;  de88dffb <pg0+1e4f6ffb/3fc67400>
   d:   0f 87 a0 12 00 00         ja     12b3 <_EIP+0x12b3>
Code;  de88e001 <pg0+1e4f7001/3fc67400>
  13:   ff                        .byte 0xff
Code;  de88e002 <pg0+1e4f7002/3fc67400>
  14:   24                        .byte 0x24

 <0>Kernel panic - not syncing: Fatal exception in interrupt

Change History

02/05/07 06:50:12 changed by mrenzmann

  • version set to trunk.