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 on
On Tue, Nov 29, 2016 at 3:58 PM, Eric Dumazet wrote:
> On Tue, 2016-11-29 at 11:26 +0100, Andrey Konovalov wrote:
>> On Sat, Nov 26, 2016 at 9:05 PM, Eric Dumazet wrote:
>> >> I actually see multiple places where skb_network_offset() is used as
>> >> an argument to skb_pull().
>> >> So I guess ev
On Tue, 2016-11-29 at 11:26 +0100, Andrey Konovalov wrote:
> On Sat, Nov 26, 2016 at 9:05 PM, Eric Dumazet wrote:
> >> 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 th
On Sat, Nov 26, 2016 at 9:05 PM, Eric Dumazet wrote:
>> 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.
I'm not sure that was the int
On Mon, 2016-11-28 at 23:19 +0100, Florian Westphal wrote:
> It currently returns -EINVAL in cases where skb wasn't changed/altered
> (e.g. because it doesn't have a fragment header), so we should ACCEPT in
> that case.
>
Maybe nf_ct_frag6_queue() should return direct NF_ codes then ...
Eric Dumazet wrote:
> On Mon, 2016-11-28 at 22:34 +0100, Florian Westphal wrote:
> > Eric Dumazet wrote:
> > > > Might be a bug added in commit daaa7d647f81f3
> > > > ("netfilter: ipv6: avoid nf_iterate recursion")
> > > >
> > > > Florian, what do you think of dropping a packet that presumably w
On Mon, 2016-11-28 at 22:34 +0100, Florian Westphal wrote:
> Eric Dumazet wrote:
> > > Might be a bug added in commit daaa7d647f81f3
> > > ("netfilter: ipv6: avoid nf_iterate recursion")
> > >
> > > Florian, what do you think of dropping a packet that presumably was
> > > mangled badly by nf_ct_f
Eric Dumazet wrote:
> > Might be a bug added in commit daaa7d647f81f3
> > ("netfilter: ipv6: avoid nf_iterate recursion")
> >
> > Florian, what do you think of dropping a packet that presumably was
> > mangled badly by nf_ct_frag6_queue() ?
ipv4 definitely frees malformed packets.
In general, I
On Mon, 2016-11-28 at 13:05 -0800, Eric Dumazet wrote:
> On Mon, 2016-11-28 at 11:47 -0800, Eric Dumazet wrote:
> > On Mon, 2016-11-28 at 20:34 +0100, Dmitry Vyukov wrote:
> > > On Mon, Nov 28, 2016 at 8:04 PM, 'Andrey Konovalov' via syzkaller
> >
> > > > Hi Eric,
> > > >
> > > > As far as I can s
On Mon, 2016-11-28 at 11:47 -0800, Eric Dumazet wrote:
> On Mon, 2016-11-28 at 20:34 +0100, Dmitry Vyukov wrote:
> > On Mon, Nov 28, 2016 at 8:04 PM, 'Andrey Konovalov' via syzkaller
>
> > > Hi Eric,
> > >
> > > As far as I can see, skb_network_offset() becomes negative after
> > > pskb_pull(skb,
On Mon, 2016-11-28 at 20:34 +0100, Dmitry Vyukov wrote:
> On Mon, Nov 28, 2016 at 8:04 PM, 'Andrey Konovalov' via syzkaller
> > Hi Eric,
> >
> > As far as I can see, skb_network_offset() becomes negative after
> > pskb_pull(skb, (u8 *) (fhdr + 1) - skb->data) in nf_ct_frag6_queue().
> > At least I
On Mon, Nov 28, 2016 at 8:04 PM, 'Andrey Konovalov' via syzkaller
wrote:
> On Mon, Nov 28, 2016 at 7:50 PM, Eric Dumazet wrote:
>> On Sat, 2016-11-26 at 20:07 +0100, Andrey Konovalov wrote:
>>> On Sat, Nov 26, 2016 at 7:28 PM, 'Eric Dumazet' via syzkaller
>>> wrote:
>>> > On Sat, Nov 26, 2016 at
On Mon, Nov 28, 2016 at 7:50 PM, Eric Dumazet wrote:
> On Sat, 2016-11-26 at 20:07 +0100, Andrey Konovalov wrote:
>> On Sat, Nov 26, 2016 at 7:28 PM, 'Eric Dumazet' via syzkaller
>> wrote:
>> > On Sat, Nov 26, 2016 at 9:30 AM, Dmitry Vyukov wrote:
>> >> Hello,
>> >>
>> >> The following program t
On Sat, 2016-11-26 at 20:07 +0100, Andrey Konovalov wrote:
> On Sat, Nov 26, 2016 at 7:28 PM, 'Eric Dumazet' via syzkaller
> wrote:
> > On Sat, Nov 26, 2016 at 9:30 AM, Dmitry Vyukov wrote:
> >> Hello,
> >>
> >> The following program triggers GPF in eth_header:
> >>
> >> https://gist.githubuserco
2016-11-26 12:05 GMT-08:00 Eric Dumazet :
>> 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_pu
> 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 l
On Sat, Nov 26, 2016 at 7:28 PM, 'Eric Dumazet' via syzkaller
wrote:
> On Sat, Nov 26, 2016 at 9:30 AM, Dmitry Vyukov wrote:
>> Hello,
>>
>> The following program triggers GPF in eth_header:
>>
>> https://gist.githubusercontent.com/dvyukov/613cadf05543b55a419f237e419cd495/raw/5471231523d1a07c3de5
On Sat, Nov 26, 2016 at 9:30 AM, Dmitry Vyukov wrote:
> Hello,
>
> The following program triggers GPF in eth_header:
>
> https://gist.githubusercontent.com/dvyukov/613cadf05543b55a419f237e419cd495/raw/5471231523d1a07c3de55f11f87472c2816ee06c/gistfile1.txt
>
> On commit 16ae16c6e5616c084168740990fc
Hello,
The following program triggers GPF in eth_header:
https://gist.githubusercontent.com/dvyukov/613cadf05543b55a419f237e419cd495/raw/5471231523d1a07c3de55f11f87472c2816ee06c/gistfile1.txt
On commit 16ae16c6e5616c084168740990fc508bda6655d4 (Nov 24).
BUG: unable to handle kernel paging reques
19 matches
Mail list logo
