Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 584378 - sys-kernel/hardened-sources-4.4.8-r1 - PAX: size overflow detected in function skb_headers_offset_update net/core/skbuff.c:976
Summary: sys-kernel/hardened-sources-4.4.8-r1 - PAX: size overflow detected in functio...
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Hardened (show other bugs)
Hardware: AMD64 Linux
: Normal normal (vote)
Assignee: The Gentoo Linux Hardened Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-28 09:17 UTC by David Zero
Modified: 2018-10-12 00:44 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Panic! at the Kernel (panic.jpg,832.42 KB, image/jpeg)
2016-05-28 09:17 UTC, David Zero
Details
dmesg with added printk (dmesg,65.40 KB, text/plain)
2016-05-28 14:01 UTC, Amadeusz Sławiński
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Zero 2016-05-28 09:17:32 UTC
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.
Comment 1 PaX Team 2016-05-28 11:29:48 UTC
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.
Comment 2 Amadeusz Sławiński 2016-05-28 14:01:04 UTC
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
Comment 3 PaX Team 2016-05-28 14:47:36 UTC
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.
Comment 4 Anthony Basile gentoo-dev 2016-07-21 16:39:19 UTC
(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?
Comment 5 David Zero 2016-07-21 20:52:26 UTC
(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.
Comment 6 PaX Team 2016-07-21 21:19:01 UTC
(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).
Comment 7 Rick Farina (Zero_Chaos) gentoo-dev 2016-09-12 18:14:50 UTC
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.
Comment 8 PaX Team 2016-09-13 13:27:49 UTC
(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.
Comment 9 Anthony Basile gentoo-dev 2016-10-01 14:22:55 UTC
can you test hardened-sources-4.7.6 because its the next stable candidate.
Comment 10 PaX Team 2016-10-01 15:36:50 UTC
(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 .
Comment 11 Rick Farina (Zero_Chaos) gentoo-dev 2016-10-18 18:41:26 UTC
The related code appeared to change in 4.7.7, but the bug still seems to exist in hardened-sources-4.7.7
Comment 12 Will S 2017-03-06 03:35:54 UTC
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