netdev - Re: [PATCHv6 net-next 1/2] ipv6: do not match device when remove source route

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]

Message-ID: <ZN4MP+9wi5w9AL7h@shredder>
Date: Thu, 17 Aug 2023 15:02:07 +0300
From: Ido Schimmel <idosch@...sch.org>
To: Hangbin Liu <liuhangbin@...il.com>
Cc: netdev@...r.kernel.org, "David S . Miller" <davem@...emloft.net>,
	David Ahern <dsahern@...nel.org>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Thomas Haller <thaller@...hat.com>
Subject: Re: [PATCHv6 net-next 1/2] ipv6: do not match device when remove
 source route

On Wed, Aug 16, 2023 at 02:07:23PM +0800, Hangbin Liu wrote:
> After deleting an IPv6 address on an interface and cleaning up the
> related preferred source entries, it is important to ensure that all
> routes associated with the deleted address are properly cleared. The
> current implementation of rt6_remove_prefsrc() only checks the preferred
> source addresses bound to the current device. However, there may be
> routes that are bound to other devices but still utilize the same
> preferred source address.
> 
> To address this issue, it is necessary to also delete entries that are
> bound to other interfaces but share the same source address with the
> current device. Failure to delete these entries would leave routes that
> are bound to the deleted address unclear. Here is an example reproducer
> (I have omitted unrelated routes):
> 
> + ip link add dummy1 type dummy
> + ip link add dummy2 type dummy
> + ip link set dummy1 up
> + ip link set dummy2 up
> + ip addr add 1:2:3:4::5/64 dev dummy1
> + ip route add 7:7:7:0::1 dev dummy1 src 1:2:3:4::5
> + ip route add 7:7:7:0::2 dev dummy2 src 1:2:3:4::5
> + ip -6 route show
> 1:2:3:4::/64 dev dummy1 proto kernel metric 256 pref medium
> 7:7:7::1 dev dummy1 src 1:2:3:4::5 metric 1024 pref medium
> 7:7:7::2 dev dummy2 src 1:2:3:4::5 metric 1024 pref medium
> + ip addr del 1:2:3:4::5/64 dev dummy1
> + ip -6 route show
> 7:7:7::1 dev dummy1 metric 1024 pref medium
> 7:7:7::2 dev dummy2 src 1:2:3:4::5 metric 1024 pref medium
> 
> As Ido reminds, in IPv6, the preferred source address is looked up in
> the same VRF as the first nexthop device, which is different with IPv4.
> So, while removing the device checking, we also need to add an
> ipv6_chk_addr() check to make sure the address does not exist on the other
> devices of the rt nexthop device's VRF.
> 
> After fix:
> + ip addr del 1:2:3:4::5/64 dev dummy1
> + ip -6 route show
> 7:7:7::1 dev dummy1 metric 1024 pref medium
> 7:7:7::2 dev dummy2 metric 1024 pref medium
> 
> Reported-by: Thomas Haller <thaller@...hat.com>
> Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2170513
> Fixes: c3968a857a6b ("ipv6: RTA_PREFSRC support for ipv6 route source address selection")
> Signed-off-by: Hangbin Liu <liuhangbin@...il.com>

Reviewed-by: Ido Schimmel <idosch@...dia.com>

But I suggest removing the Fixes tag given the patch is targeted at
net-next and does not fix a regression (never worked).