linux-kernel - Re: [PATCH v2] net/ipv6: allow device-only routes via the multipath API

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <dcbaec83-095e-40a7-a51c-8688cbcd0592@6wind.com>
Date: Mon, 1 Dec 2025 16:38:25 +0100
From: Nicolas Dichtel <nicolas.dichtel@...nd.com>
To: azey <me@...y.net>
Cc: Jakub Kicinski <kuba@...nel.org>, David Ahern <dsahern@...nel.org>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>,
 netdev <netdev@...r.kernel.org>, linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] net/ipv6: allow device-only routes via the multipath
 API

Le 28/11/2025 à 18:49, azey a écrit :
> On 2025-11-28 17:28:41 +0100  Nicolas Dichtel <nicolas.dichtel@...nd.com> wrote:
>> Le 28/11/2025 à 16:54, azey a écrit :
>>>> On 2025-11-28 09:38:07 +0100  Nicolas Dichtel <nicolas.dichtel@...nd.com> wrote:
>>>>> With IPv6, unlike IPv4, the ECMP next hops can be added one by one. Your commit
>>>>> doesn't allow this:
>>>
>>> Hold on, I think I understand what you actually meant by this, sorry.
>>> I got too focused on regressions from the discussion in v1, I'll make
>>> a v3 of the patch that allows dev-only routes to be added via append.
>> Yes, that is what I pointed out.
>>
>> Please, add some self-tests to show that there is no regression. You probably
>> have to test different combinations of NLM_F_* flags. See:
>>
>> https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/ip/iproute.c#n2418
> 
> Will do, thanks for the pointer.
> One last thing I'd like to clarify though: would this behavior not also
> itself be considered a regression?
> 
> Currently the add and append routes get added separately, and someone
> could theoretically be relying on the kernel always picking the last
> route instead of making them multipath - essentially still the same
> v1 regression.
That's a good question. I let others speak.
But using the nexthop API would definitely close this question. I wonder why
using this API is not possible for you.

> 
> If not, would it also be acceptable for just any non-RTPROT_KERNEL
> routes to automatically be made multipath like this? It's a simple fix,
> it'd make appending work and it'd still prevent the specific v1
> regression for the case of two interfaces on the same subnet - example
> diff attached.

I don't think that the protocol field is reliable. The user can set it to
whatever he wants.