lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Tue, 28 Feb 2017 17:49:20 -0800
From:   David Ahern <>
To:     Eric Dumazet <>
Cc:     Eric Dumazet <>,
        Dmitry Vyukov <>,
        David Miller <>,
        Hideaki YOSHIFUJI <>,
        netdev <>,
        LKML <>,
        Cong Wang <>,
        Yuchung Cheng <>,
        Willem de Bruijn <>,
        syzkaller <>
Subject: Re: net: GPF in rt6_nexthop_info

On 2/28/17 3:14 PM, Eric Dumazet wrote:
> On Tue, Feb 28, 2017 at 3:09 PM, David Ahern <> wrote:
>> On 2/28/17 5:10 AM, Eric Dumazet wrote:
>>> David, rt->rt6i_idev can be NULL.
>> Do you know of an example where rt6i_idev can be NULL - besides the
>> null_entry rt which is null only because of init order?
> I might have been mistaken, but many points in net/ipv6/route.c test
> rt->rt6i_idev being NULL or not before dereferencing it.
> Maybe other rts (other than null_entry) share this property.

Seen those and always been confused that an L3 route object does not
require the L3 addr struct for the device.

Code wise the struct is allocated for all net devices at registration as
long as mtu >= 1280. If it is not allocated, routes referencing the
device fail with ENODEV (idev check in ip6_route_info_create). Putting
that together I can't see how a standard ipv6 rt other than the
null_entry can reference a null rt6i_idev.

Powered by blists - more mailing lists