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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 24 Jan 2017 20:39:32 -0500 (EST)
From:   David Miller <>
Subject: Re: [PATCH net-next] net: ipv6: ignore null_entry on route dumps

From: David Ahern <>
Date: Tue, 24 Jan 2017 18:35:02 -0700

> On 1/23/17 9:51 AM, David Ahern wrote:
>> On 1/22/17 9:58 PM, David Miller wrote:
>>> David, please slow down.
>>> How is the NULL entry getting selected to be dumped and passed
>>> down here in the first place?
>> The null_entry might be a 'marker' but is integral to the ipv6 fib.
> As I mentioned in my last response the null_entry is tb6_root.leaf for all tables making it part of the table. Since the dump walks the table and sends each route to rt6_dump_route, the dump includes the null_entry.
> ip6_null_entry->rt6i_idev is NULL because ip6_route_net_init is run before addrconf_init has initialized the loopback device.
> Given that, it seems like a check is needed somewhere ...  be it 'rt == net->ipv6.ip6_null_entry' in rt6_dump_route or fib6_dump_node, or a check for rt6i_idev NULL in rt6_fill_node.
> You marked the last patch as changes needed meaning another needs to be sent.
> Suggestion?

Probably putting the check as high in the call chain as possible, via
fib6_dump_node(), is the best.

Although, it's troubling that we are trying to dump unfinished entries
simply because of initialization order.  It's arguable that this is
the real thing to fix.

The loopback device is a hard dependency which the ipv6 stack has
because of how it does statistics and other things.

Powered by blists - more mailing lists