netdev - Re: POSSIBLE BUG: selftests/net/fcnal-test.sh: [FAIL] in vrf "bind

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]

Date: Wed, 31 May 2023 20:11:41 +0200
From: Guillaume Nault <gnault@...hat.com>
To: Mirsad Todorovac <mirsad.todorovac@....unizg.hr>
Cc: netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Shuah Khan <shuah@...nel.org>, linux-kernel@...r.kernel.org,
	linux-kselftest@...r.kernel.org
Subject: Re: POSSIBLE BUG: selftests/net/fcnal-test.sh: [FAIL] in vrf "bind -
 ns-B IPv6 LLA" test

On Wed, May 24, 2023 at 02:17:09PM +0200, Mirsad Todorovac wrote:
> Hi,

Hi Mirsad,

> The very recent 6.4-rc3 kernel build with AlmaLinux 8.7 on LENOVO 10TX000VCR
> desktop box fails one test:
> 
> [root@...t net]# ./fcnal-test.sh
> [...]
> TEST: ping out, vrf device+address bind - ns-B loopback IPv6                  [ OK ]
> TEST: ping out, vrf device+address bind - ns-B IPv6 LLA                       [FAIL]
> TEST: ping in - ns-A IPv6                                                     [ OK ]
> [...]
> Tests passed: 887
> Tests failed:   1
> [root@...t net]#

This test also fails on -net. The problem is specific to ping sockets
(same test passes with raw sockets). I believe this test has always
failed since fcnal-test.sh started using net.ipv4.ping_group_range
(commit e71b7f1f44d3 ("selftests: add ping test with ping_group_range
tuned")).

The executed command is:

ip netns exec ns-A ip vrf exec red /usr/bin/ping6 -c1 -w1 -I 2001:db8:3::1 fe80::a846:b5ff:fe4c:da4e%eth1

So ping6 is executed inside VRF 'red' and sets .sin6_scope_id to 'eth1'
(which is a slave device of VRF 'red'). Therefore, we have
sk->sk_bound_dev_if == 'red' and .sin6_scope_id == 'eth1'. This fails
because ping_v6_sendmsg() expects them to be equal:

static int ping_v6_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
{
...
                if (__ipv6_addr_needs_scope_id(ipv6_addr_type(daddr)))
                        oif = u->sin6_scope_id;
...
        if ((__ipv6_addr_needs_scope_id(addr_type) && !oif) ||
            (addr_type & IPV6_ADDR_MAPPED) ||
            (oif && sk->sk_bound_dev_if && oif != sk->sk_bound_dev_if)) <-- oif='eth1', but ->sk_bound_dev_if='red'
                return -EINVAL;
...
}

I believe this condition should be relaxed to allow the case where
->sk_bound_dev_if is oif's master device (and maybe there are other
VRF cases to also consider).