[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1480436114.18162.143.camel@edumazet-glaptop3.roam.corp.google.com>
Date: Tue, 29 Nov 2016 08:15:14 -0800
From: Eric Dumazet <eric.dumazet@...il.com>
To: Andrey Konovalov <andreyknvl@...gle.com>
Cc: syzkaller <syzkaller@...glegroups.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
David Miller <davem@...emloft.net>,
Tom Herbert <tom@...bertland.com>,
Alexander Duyck <aduyck@...antis.com>,
Hannes Frederic Sowa <hannes@...essinduktion.org>,
Jiri Benc <jbenc@...hat.com>,
Sabrina Dubroca <sd@...asysnail.net>,
netdev <netdev@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: net: GPF in eth_header
On Tue, 2016-11-29 at 16:31 +0100, Andrey Konovalov wrote:
=
> The issue is not with skb_network_offset(), but with __skb_pull()
> using skb_network_offset() as an argument.
>
No. The issue can happen with _any_ __skb_pull() with a 'negative'
argument, on 64bit arches.
skb_network_offset() is only one of the many cases this could happen if
a bug is added at some random place, including memory corruption from
a different kernel layer, or buggy hardware.
> I'm not sure what would be the beast way to fix this, to add a check
> before every __skb_pull(skb_network_offset()), to fix __skb_pull() to
> work with signed ints, to add BUG_ON()'s in __skb_pull, or something
> else.
>
> What I meant is that you fixed this very instance of the bug, and I'm
> pointing out that a similar one might hit us again.
As I said, adding a check in skb_network_offset() would not be generic
enough.
Sure, we can be proactive and add tests everywhere in the kernel, but we
also want to keep it reasonably fast.
Powered by blists - more mailing lists