Panic with WEP

[Martin Whitlock]

I have experienced the same problem, but in an ARM environment with 
0.0.1 release and 2.4.[18|19] kernel. I have made some debugging and it 
turns out that there is a problem with hostbased wep decryption together 
with fragmented frames. When I use a Lucent Orinoco client in windows it 
seems as the defualt fragmentation size is 500 bytes, which means that a 
lot of packets will be fragmented. I beleive that it is when the last 
fragmented frame is decrypted, the resulting buffer size is false.
Jouni, could this be the case?

I have sniffed the traffic with Etherreal and the frames sent from the 
client seem to be in perfect order. The problem is easily repeated by 
configuring the AP with host_decrypt = 1and letting a fragmenting client 
ping with a packetsize > frag.

/Martin


Justin Reigle wrote:

> I've recently been playing with hostap, 802.1x, and WEP in conjunction
> with a Windows XP (post-SP1) station.
>
> Simple data transfer works fine (i.e. ping). If I do anything more than
> that, it doesn't take long before a panic occurs (reproducable).
>
> I managed to track the problem down to the line of code where a null
> pointer is dereferenced. The kernel version is 2.4.17. The code is in
> linux/net/core/dev.c:netif_rx. The macro, dev_hold() is called, with
> skb->dev passed to it. Here skb->dev is null, which causes the panic.
>
> I'm not sure why skb->dev is null, or where the actual bug is. This is
> a daily snapshot of the hostap code from this past sunday (march 16th).
> I see the same behavior with a month old snapshot.
>
> Here's some ksymoops output to provide a little more information:
> --------------------
>
> CPU:    0
> EIP:    0010:[<c0198dcd>]    Not tainted
> EFLAGS: 00010046
> eax: 00000000   ebx: c3a92ea0   ecx: 00000000   edx: c3a92eb0
> esi: 00000246   edi: 00000000   ebp: c3a63e08   esp: c3a63cd0
> ds: 0018   es: 0018   ss: 0018
> Process boa (pid: 1305, stackpage=c3a63000)
> Stack: c3a8c000 c356382e 00000283 00000000 00000000 c3a92ea0 c3a92efc 
> c784b69b
>        c3a92ea0 c11d6e00 c376b820 c11ad7e0 000001f4 c3435648 00000010 
> 08000004
>        00000096 691000a7 abc9c507 c3563852 c38949ac 00000000 15b28679 
> c3a63d8c
> Call Trace: [<c784b69b>] [<c7847a2d>] [<c019570c>] [<c784a88d>] 
> [<c783d7f9>]
>    [<c01958bb>] [<c0195a33>] [<c784c05b>] [<c784b74f>] [<c0115fde>] 
> [<c0115e43>]
>    [<c01fc382>] [<c01cb987>] [<c01929a1>] [<c019570c>] [<c784c29f>] 
> [<c0192aba>]
>    [<c012c126>] [<c0115651>] [<c0106cf3>]
> Code: ff 80 dc 00 00 00 b8 e0 26 26 c0 83 c0 0c 89 43 08 8b 50 08
>
> >>EIP; c0198dcd <netif_rx+4d/110>   <=====
> Trace; c784b69b <[hostap]hostap_proc+573b/13100>
> Trace; c7847a2d <[hostap]hostap_proc+1acd/13100>
> Trace; c019570c <alloc_skb+dc/1b0>
> Trace; c784a88d <[hostap]hostap_proc+492d/13100>
> Trace; c783d7f9 <[hostap]hostap_info_process+55/1f0>
> Trace; c01958bb <kfree_skbmem+b/70>
> Trace; c0195a33 <__kfree_skb+113/120>
> Trace; c784c05b <[hostap]hostap_proc+60fb/13100>
> Trace; c784b74f <[hostap]hostap_proc+57ef/13100>
> Trace; c0115fde <tasklet_action+3e/70>
> Trace; c0115e43 <do_softirq+53/a0>
> Trace; c01fc382 <stext_lock+26a2/3516>
> Trace; c01cb987 <inet_recvmsg+37/50>
> Trace; c01929a1 <sock_recvmsg+31/b0>
> Trace; c019570c <alloc_skb+dc/1b0>
> Trace; c784c29f <[hostap]hostap_proc+633f/13100>
> Trace; c0192aba <sock_read+8a/a0>
> Trace; c012c126 <sys_read+96/d0>
> Trace; c0115651 <sys_time+11/50>
> Trace; c0106cf3 <system_call+33/40>
> Code;  c0198dcd <netif_rx+4d/110>
> 00000000 <_EIP>:
> Code;  c0198dcd <netif_rx+4d/110>   <=====
>    0:   ff 80 dc 00 00 00         incl   0xdc(%eax)   <=====
> Code;  c0198dd3 <netif_rx+53/110>
>    6:   b8 e0 26 26 c0            mov    $0xc02626e0,%eax
> Code;  c0198dd8 <netif_rx+58/110>
>    b:   83 c0 0c                  add    $0xc,%eax
> Code;  c0198ddb <netif_rx+5b/110>
>    e:   89 43 08                  mov    %eax,0x8(%ebx)
> Code;  c0198dde <netif_rx+5e/110>
>   11:   8b 50 08                  mov    0x8(%eax),%edx
>
>  <0>Kernel panic: Aiee, killing interrupt handler