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: <19a969f919b.facf84276222.4894043454892645830@azey.net>
Date: Tue, 18 Nov 2025 12:00:31 +0100
From: azey <me@...y.net>
To: "nicolasdichtel" <nicolas.dichtel@...nd.com>
Cc: "David Ahern" <dsahern@...nel.org>,
	"David S. Miller" <davem@...emloft.net>,
	"Eric Dumazet" <edumazet@...gle.com>,
	"Jakub Kicinski" <kuba@...nel.org>,
	"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] net/ipv6: allow device-only routes via the multipath
 API

On 2025-11-18 10:05:55, +0100 Nicolas Dichtel wrote:
> If I remember well, it was to avoid merging connected routes to ECMP routes.
> For example, fe80:: but also if two interfaces have an address in the same
> prefix. With the current code, the last route will always be used. With this
> patch, packets will be distributed across the two interfaces, right?
> If yes, it may cause regression on some setups.

Thanks! Yes, with this patch routes with the same destination and metric automatically
become multipath. From my testing, for link-locals this shouldn't make a difference
as the interface must always be specified with % anyway.

For non-LL addresses, this could indeed cause a regression in obscure setups. In my
opinion though, I feel that it is very unlikely anyone who has two routes with the
same prefix and metric (which AFAIK, isn't really a supported configuration without
ECMP anyway) relies on this quirk. The most plausible setup relying on this I can
think of would be a server with two interfaces on the same L2 segment, and a
firewall somewhere that only allows the source address of one interface through.

IMO, setups like that are more of a misconfiguration than a "practical use case"
that'd make this a real regression, but I'd completely understand if it'd be enough
to block this.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ