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: <e4368ed8-154d-4656-838f-4005287d4394@kernel.org>
Date: Mon, 12 Jan 2026 08:25:31 -0700
From: David Ahern <dsahern@...nel.org>
To: Ido Schimmel <idosch@...dia.com>, netdev@...r.kernel.org
Cc: davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com,
 edumazet@...gle.com, horms@...nel.org, petrm@...dia.com
Subject: Re: [PATCH net-next 1/5] selftests: fib-onlink: Remove "wrong nexthop
 device" IPv4 tests

On 1/11/26 5:08 AM, Ido Schimmel wrote:
> According to the test description, these tests fail because of a wrong
> nexthop device:
> 
>  # ./fib-onlink-tests.sh -v
>  [...]
>  COMMAND: ip ro add table 254 169.254.101.102/32 via 169.254.3.1 dev veth1 onlink
>  Error: Nexthop has invalid gateway.
> 
>  TEST: Gateway resolves to wrong nexthop device            [ OK ]
>  COMMAND: ip ro add table 1101 169.254.102.103/32 via 169.254.7.1 dev veth5 onlink
>  Error: Nexthop has invalid gateway.
> 
>  TEST: Gateway resolves to wrong nexthop device - VRF      [ OK ]
>  [...]
> 
> But this is incorrect. They fail because the gateway addresses are local
> addresses:
> 
>  # ip -4 address show
>  [...]
>  28: veth3@...7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link-netns peer_ns-Urqh3o
>      inet 169.254.3.1/24 scope global veth3
>  [...]
>  32: veth7@...1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master lisa state UP group default qlen 1000 link-netns peer_ns-Urqh3o
>      inet 169.254.7.1/24 scope global veth7
> 
> Therefore, using a local address that matches the nexthop device fails
> as well:
> 
>  # ip ro add table 254 169.254.101.102/32 via 169.254.3.1 dev veth3 onlink
>  Error: Nexthop has invalid gateway.
> 
> Using a gateway address with a "wrong" nexthop device is actually valid
> and allowed:
> 
>  # ip route get 169.254.1.2
>  169.254.1.2 dev veth1 src 169.254.1.1 uid 0
>  # ip ro add table 254 169.254.101.102/32 via 169.254.1.2 dev veth3 onlink
>  # echo $?
>  0
> 
> Remove these tests given that their output is confusing and that the
> scenario that they are testing is already covered by other tests.
> 
> A subsequent patch will add tests for the nexthop device mismatch
> scenario.
> 
> Reviewed-by: Petr Machata <petrm@...dia.com>
> Signed-off-by: Ido Schimmel <idosch@...dia.com>
> ---
>  tools/testing/selftests/net/fib-onlink-tests.sh | 6 ------
>  1 file changed, 6 deletions(-)
> 

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



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ