#408: intermittent kernel lockup when using VPN and WPA over MadWifi
---------------------------------+------------------------------------------
      Reporter:  eaton.lists     |       Owner:                                 
     
          Type:  defect          |      Status:  new                            
     
      Priority:  critical        |   Milestone:  version 0.9.0 - move to new 
codebase
     Component:  madwifi: other  |     Version:  trunk                          
     
    Resolution:                  |    Keywords:  vpn ipsec wpa panic hang       
     
Patch_attached:  1               |  
---------------------------------+------------------------------------------
Changes (by [EMAIL PROTECTED]):

  * patch_attached:  0 => 1
  * keywords:  vpn ipsec panic hang => vpn ipsec wpa panic hang
  * priority:  major => critical

Comment:

 The crash was happening because madwifi was occasionally passing a
 negative length to the "extra headroom" parameter when expanding a skb.
 The skb code didn't cope with that particularly gracefully, instead it
 corrupted memory of the object allocated just before the skb data that was
 being updated.  That patch checks for that case, and sets the extra
 headroom parameter to zero instead.

 The problem was not specific to either WPA or a VPN - all that was
 required was for a skb reused by madwifi to have more headroom available
 than the madwifi code needed.  I think WPA and the VPN tended to put more
 skbuffs with lots of headroom in circulation, increasing the likelihood
 that madwifi would hit one and corrupt memory.

 Enabling the debug functions in mm/slab.c made the problem much more
 obvious, they caught the overwrite almost as soon as it happened.

 Signed-off-by: Brian Eaton <[EMAIL PROTECTED]>

-- 
Ticket URL: <http://madwifi.org/ticket/408>
MadWifi <http://madwifi.org/>
Multiband Atheros Driver for Wireless Fidelity

Reply via email to