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] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 07 Sep 2014 21:59:43 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	eric.dumazet@...il.com
Cc:	nicolas.dichtel@...nd.com, therbert@...gle.com,
	alexander.h.duyck@...el.com, netdev@...r.kernel.org
Subject: Re: [PATCH net] ipv6: refresh rt6i_genid in ip6_pol_route()

From: Eric Dumazet <eric.dumazet@...il.com>
Date: Sun, 07 Sep 2014 21:43:54 -0700

> On Sun, 2014-09-07 at 21:27 -0700, David Miller wrote:
>> From: Eric Dumazet <eric.dumazet@...il.com>
>> Date: Sun, 07 Sep 2014 21:18:25 -0700
>> 
>> > On Sun, 2014-09-07 at 15:54 -0700, David Miller wrote:
>> > 
>> >> This might be broken.
>> >> 
>> >> We are dealing here with persistent entries in the ipv6 routine trie.
>> >> 
>> >> If you just bump the genid on the next person to look it up, other
>> >> sockets and cached entities might not have validated the route yet,
>> >> and now will falsely see the route as valid.  We have to ensure that
>> >> they too drop this route and perform a relookup.
>> > 
>> > I am confused, I thought it was the role of the cookie.
>> > 
>> > (Ie socket has to store its own cookie to be able to validate a route)
>> > 
>> > Before 6f3118b571b8 patch, how was this done anyway ?
>> > 
>> > If persistent routes cannot refresh the genid, then they are useless ?
>> 
>> I just speak about the genid aspect.
>> 
>> I understand that cookie (via node->fn_sernum) invalidates the path
>> in the fib_trie, but the genid protects against other circumstances
>> (matching IPSEC rule, f.e.)
>> 
>> You have to make sure all other sockets did a full route lookup
>> (including IPSEC) before you can safely adjust the genid.
>> 
>> I could be wrong, recheck my analysis please :-)
> 
> So this whole genid protection can not work, unless we make sure a
> socket cannot share a route with another socket.
> 
> This means we have to clone all routes.

I'm willing to revert the change in question if you think that's the
sanest way forward.

The bug fix for more obscure use cases (IPSEC) if pointless if it
breaks more common things (TCP input route caching).
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists