Created attachment 435592 [details] Panic! at the Kernel I can make Linux panic reliably upon attempting to connect to a wireless access point via wpa_supplicant. "PAX: size overflow detected in function skb_headers_offset_update net/core/skbuff.c:976 cicus.647_38 min, count: 10, decl: network_header; num: 0; context: sk_buff;" The system locks up completely, and so I'm not easily able to copy+paste the stack trace; I've provided a picture instead.
first of all, you can boot with pax_size_overflow_report_only to not panic the system on a size overflow event then you can grab dmesg. second, this was reported at https://forums.grsecurity.net/viewtopic.php?f=3&t=4448 already but we got no feedback, perhaps you could help with debugging with the following patch: --- a/net/core/skbuff.c 2016-05-20 23:35:19.471717291 +0200 +++ b/net/core/skbuff.c 2016-05-28 13:07:56.328808252 +0200 @@ -973,6 +973,7 @@ /* {transport,network,mac}_header and tail are relative to skb->head */ if (skb_transport_header_was_set(skb)) skb->transport_header += off; + printk("PAX: network_header:%x off:%x\n", (u32)skb->network_header, off); skb->network_header += off; if (skb_mac_header_was_set(skb)) skb->mac_header += off; and report back with dmesg. PS: hardened guys, can you please add Emese to any size overflow related bugs please? you used to do that in the past already but this is like the second bug lately where it hasn't happened.
Created attachment 435638 [details] dmesg with added printk Attached is full dmesg with added log from my machine. [ 28.005247] PAX: network_header:0 off:ffffffb4
can you also enable frame pointers to get a precise backtrace? in any case, this looks like a real bug, the code's trying to decrease a 0 network_header value, that can't be right. it's probably worth a shot at reporting this upstream at this point.
(In reply to PaX Team from comment #3) > can you also enable frame pointers to get a precise backtrace? in any case, > this looks like a real bug, the code's trying to decrease a 0 network_header > value, that can't be right. it's probably worth a shot at reporting this > upstream at this point. this bug is a couple of months old with no response from the original reporter. i don't want to just close it because making a kernel panic is serious enough. @pipacs, did you guys look at this at all?
(In reply to Anthony Basile from comment #4) > (In reply to PaX Team from comment #3) > > can you also enable frame pointers to get a precise backtrace? in any case, > > this looks like a real bug, the code's trying to decrease a 0 network_header > > value, that can't be right. it's probably worth a shot at reporting this > > upstream at this point. > > this bug is a couple of months old with no response from the original > reporter. i don't want to just close it because making a kernel panic is > serious enough. > > @pipacs, did you guys look at this at all? My apologies, I was only able to replicate this behavior with a specific access-point which I no longer have access to, which is why I haven't responded.
(In reply to Anthony Basile from comment #4) > (In reply to PaX Team from comment #3) > > can you also enable frame pointers to get a precise backtrace? in any case, > > this looks like a real bug, the code's trying to decrease a 0 network_header > > value, that can't be right. it's probably worth a shot at reporting this > > upstream at this point. > > @pipacs, did you guys look at this at all? nothing beyond what you see above, it's not exactly my area of expertise so i can only repeat what i said at the time, ask upstream about whether it's a bug and if so how to fix it (and work with the original reporter as i/we can't reproduce it).
I am reliably getting this with 4.4.8-r1 when flipping into monitor mode. "airmon-ng start <some wlan interface>" seems to incredibly reliably reproduce this on that kernel. I'm going to try to update my kernel because if this is a solved bug we should all move on, but if you want a test case the above should work pretty easily.
(In reply to Rick Farina (Zero_Chaos) from comment #7) > I'm going to try to update my kernel because if this is a solved bug we > should all move on, but if you want a test case the above should work pretty > easily. nothing was fixed on our side since we still don't know what the real problem is. you should really report this upstream and see what they say.
can you test hardened-sources-4.7.6 because its the next stable candidate.
(In reply to Anthony Basile from comment #9) > can you test hardened-sources-4.7.6 because its the next stable candidate. it's not fixed yet but at least it is reported upstream now: http://marc.info/?l=linux-netdev&m=147523522324068&w=2 .
The related code appeared to change in 4.7.7, but the bug still seems to exist in hardened-sources-4.7.7
I'm experiencing the same issue on 4.9.11-hardened . Steps to reproduce: # iw phy phy0 interface add mon0 type monitor # ifconfig mon0 up
