netdev - Re: [PATCH net] seg6: fix route leak for encap routes

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] [day] [month] [year] [list]

Message-ID: <051053d9-65f2-43bf-936b-c12848367acd@6wind.com>
Date: Wed, 10 Dec 2025 18:00:39 +0100
From: Nicolas Dichtel <nicolas.dichtel@...nd.com>
To: Andrea Mayer <andrea.mayer@...roma2.it>
Cc: "David S . Miller" <davem@...emloft.net>, Jakub Kicinski
 <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Eric Dumazet <edumazet@...gle.com>, David Lebrun
 <david.lebrun@...ouvain.be>, Paolo Lungaroni <paolo.lungaroni@...roma2.it>,
 David Ahern <dsahern@...nel.org>, netdev@...r.kernel.org,
 stefano.salsano@...roma2.it
Subject: Re: [PATCH net] seg6: fix route leak for encap routes

Le 10/12/2025 à 11:37, Andrea Mayer a écrit :
> On Mon,  8 Dec 2025 11:24:34 +0100
> Nicolas Dichtel <nicolas.dichtel@...nd.com> wrote:
> 
>> The goal is to take into account the device used to set up the route.
>> Before this commit, it was mandatory but ignored. After encapsulation, a
>> second route lookup is performed using the encapsulated IPv6 address.
>> This route lookup is now done in the vrf where the route device is set.
>>
> 
> Hi Nicolas,
Hi Andrea,

> 
> I've got your point. However, I'm still concerned about the implications of
> using the *dev* field in the root lookup. This field has been ignored for this
> purpose so far, so some existing configurations/scripts may need to be adapted
> to work again. The adjustments made to the self-tests below show what might
> happen.
Yes, I was wondering how users use this *dev* arg. Maybe adding a new attribute,
something like SEG6_IPTUNNEL_USE_NH_DEV will avoid any regressions.

> 
> 
>> The l3vpn tests show the inconsistency; they are updated to reflect the
>> fix. Before the commit, the route to 'fc00:21:100::6046' was put in the
>> vrf-100 table while the encap route was pointing to veth0, which is not
>> associated with a vrf.
>>
>> Before:
>>> $ ip -n rt_2-Rh5GP7 -6 r list vrf vrf-100 | grep fc00:21:100::6046
>>> cafe::1  encap seg6 mode encap segs 1 [ fc00:21:100::6046 ] dev veth0 metric 1024 pref medium
>>> fc00:21:100::6046 via fd00::1 dev veth0 metric 1024 pref medium
>>
>> After:
>>> $ ip -n rt_2-Rh5GP7 -6 r list vrf vrf-100 | grep fc00:21:100::6046
>>> cafe::1  encap seg6 mode encap segs 1 [ fc00:21:100::6046 ] dev veth0 metric 1024 pref medium
>>> $ ip -n rt_2-Rh5GP7 -6 r list | grep fc00:21:100::6046
>>> fc00:21:100::6046 via fd00::1 dev veth0 metric 1024 pref medium
>>
>> Fixes: 6c8702c60b88 ("ipv6: sr: add support for SRH encapsulation and injection with lwtunnels")
>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@...nd.com>
>> ---
>>  net/ipv6/seg6_iptunnel.c                                | 6 ++++++
>>  tools/testing/selftests/net/srv6_end_dt46_l3vpn_test.sh | 2 +-
>>  tools/testing/selftests/net/srv6_end_dt4_l3vpn_test.sh  | 2 +-
>>  tools/testing/selftests/net/srv6_end_dt6_l3vpn_test.sh  | 2 +-
>>  4 files changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/net/ipv6/seg6_iptunnel.c b/net/ipv6/seg6_iptunnel.c
>> index 3e1b9991131a..9535aea28357 100644
>> --- a/net/ipv6/seg6_iptunnel.c
>> +++ b/net/ipv6/seg6_iptunnel.c
>> @@ -484,6 +484,12 @@ static int seg6_input_core(struct net *net, struct sock *sk,
>>  	 * now and use it later as a comparison.
>>  	 */
>>  	lwtst = orig_dst->lwtstate;
>> +	if (orig_dst->dev) {
> 
> When can 'orig_dst->dev' be NULL in this context?
I was cautious to avoid any unpleasant surprises. A dst can have dst->dev set to
NULL.

Thanks,
Nicolas