Re: net: GPF in eth_header

From	Eric Dumazet <erdlkml@gmail.com>
Newsgroups	linux.kernel
Subject	Re: net: GPF in eth_header
Date	2016-11-26 21:40 +0100
Message-ID	<sHRVn-2Za-5@gated-at.bofh.it> (permalink)
References	<sHP7b-189-13@gated-at.bofh.it> <sHPTz-1JW-9@gated-at.bofh.it> <sHQwi-2dp-13@gated-at.bofh.it> <sHRsl-2MG-5@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

2016-11-26 12:05 GMT-08:00 Eric Dumazet <erdlkml@gmail.com>:
>> Hi Eric,
>>
>> The crash happens when the kernel tries to access shadow for nonmapped memory.
>>
>> The issue here is an integer overflow which happens in neigh_resolve_output().
>> skb_network_offset(skb) can return negative number, but __skb_pull()
>> accepts unsigned int as len.
>> As a result, the least significat bit in higher 32 bits of skb->data
>> gets set and we get an out-of-bounds with offset of 4 GB.
>>
>> I've attached a short reproducer, but you either need KASAN or to add
>> a BUG_ON to see the crash.
>> In this reproducer skb_network_offset() becomes negative after merging
>> two ipv6 fragments.
>>
>> I actually see multiple places where skb_network_offset() is used as
>> an argument to skb_pull().
>> So I guess every place can potentially be buggy.
>
> Well, I think the intent is to accept a negative number.
>
> This definitely was assumed by commit e1f165032c8bade authors !
>
> I guess they were using a 32bit kernel for their tests.

Correct fix would be to use

skb_push(skb, -skb_network_offset(skb));

As done in other locations...

Thread

net: GPF in eth_header Dmitry Vyukov <dvyukov@google.com> - 2016-11-26 18:40 +0100
  Re: net: GPF in eth_header Eric Dumazet <edumazet@google.com> - 2016-11-26 19:30 +0100
    Re: net: GPF in eth_header Andrey Konovalov <andreyknvl@google.com> - 2016-11-26 20:10 +0100
      Re: net: GPF in eth_header Eric Dumazet <erdlkml@gmail.com> - 2016-11-26 21:10 +0100
        Re: net: GPF in eth_header Eric Dumazet <erdlkml@gmail.com> - 2016-11-26 21:40 +0100
        Re: net: GPF in eth_header Andrey Konovalov <andreyknvl@google.com> - 2016-11-29 11:30 +0100
          Re: net: GPF in eth_header Eric Dumazet <eric.dumazet@gmail.com> - 2016-11-29 16:00 +0100
            Re: net: GPF in eth_header Andrey Konovalov <andreyknvl@google.com> - 2016-11-29 16:40 +0100
              Re: net: GPF in eth_header Eric Dumazet <eric.dumazet@gmail.com> - 2016-11-29 17:20 +0100
      Re: net: GPF in eth_header Eric Dumazet <eric.dumazet@gmail.com> - 2016-11-28 20:00 +0100
        Re: net: GPF in eth_header Andrey Konovalov <andreyknvl@google.com> - 2016-11-28 20:10 +0100
          Re: net: GPF in eth_header Dmitry Vyukov <dvyukov@google.com> - 2016-11-28 20:40 +0100
            Re: net: GPF in eth_header Eric Dumazet <eric.dumazet@gmail.com> - 2016-11-28 20:50 +0100
              Re: net: GPF in eth_header Eric Dumazet <eric.dumazet@gmail.com> - 2016-11-28 22:10 +0100
                Re: net: GPF in eth_header Eric Dumazet <eric.dumazet@gmail.com> - 2016-11-28 22:20 +0100
                Re: net: GPF in eth_header Florian Westphal <fw@strlen.de> - 2016-11-28 22:40 +0100
                Re: net: GPF in eth_header Eric Dumazet <eric.dumazet@gmail.com> - 2016-11-28 23:20 +0100
                Re: net: GPF in eth_header Florian Westphal <fw@strlen.de> - 2016-11-28 23:30 +0100
                Re: net: GPF in eth_header Eric Dumazet <eric.dumazet@gmail.com> - 2016-11-29 00:20 +0100

csiph-web