netdev - Re: [PATCHv7 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: <136fabc5-d8ed-f4a4-1aa6-5a4ec1d2b70c@kernel.org>
Date: Fri, 18 Aug 2023 18:28:50 -0600
From: David Ahern <dsahern@...nel.org>
To: Hangbin Liu <liuhangbin@...il.com>, netdev@...r.kernel.org
Cc: "David S . Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, Ido Schimmel <idosch@...sch.org>,
 Thomas Haller <thaller@...hat.com>, Ido Schimmel <idosch@...dia.com>
Subject: Re: [PATCHv7 net-next 1/2] ipv6: do not match device when remove
 source route

On 8/18/23 2:29 AM, 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
> Reviewed-by: Ido Schimmel <idosch@...dia.com>
> Signed-off-by: Hangbin Liu <liuhangbin@...il.com>
> ---
> v7: remove fixes tag
> v6:
>  - Add back the "!rt->nh" checking as Ido said this should be fixed in
>    another patch.
>  - Remove the table id checking as the preferred source address is
>    looked up in the same VRF as the first nexthop device in IPv6. not VRF
>    table like IPv4.
>  - Move the fib tests to a separate patch.
> v5: Move the addr check back to fib6_remove_prefsrc.
> v4: check if the prefsrc address still exists on other device
> v3: remove rt nh checking. update the ipv6_del_addr test descriptions
> v2: checking table id and update fib_test.sh
> ---
>  net/ipv6/route.c | 7 ++-----
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 

Reviewed-by: David Ahern <dsahern@...nel.org>