netdev - Re: net: GPF in rt6_nexthop

lists.openwall.net		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]

Message-ID: <0123e480-d82f-a161-f62f-3fd6f7dec175@cumulusnetworks.com>
Date:   Tue, 28 Feb 2017 17:49:20 -0800
From:   David Ahern <dsa@...ulusnetworks.com>
To:     Eric Dumazet <edumazet@...gle.com>
Cc:     Eric Dumazet <eric.dumazet@...il.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        David Miller <davem@...emloft.net>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        netdev <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Yuchung Cheng <ycheng@...gle.com>,
        Willem de Bruijn <willemb@...gle.com>,
        syzkaller <syzkaller@...glegroups.com>
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 <dsa@...ulusnetworks.com> 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.