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
| ||
|
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).
Powered by blists - more mailing lists