#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