netdev - Peer losing IP address after moving veth into namespace

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

Message-ID: <CAO3-PboKFJm_RmrExrUidg8t-E5efvDg7+HDzsMO6R5V1G5cAA@mail.gmail.com>
Date:   Thu, 2 Jan 2020 22:42:45 -0800
From:   Yan Zhai <yan@...udflare.com>
To:     netdev@...r.kernel.org, kernel-team <kernel-team@...udflare.com>,
        Ivan Babrou <ivan@...udflare.com>,
        Erich Heine <erich@...udflare.com>
Subject: Peer losing IP address after moving veth into namespace

Hi netdev folks,

  we have encountered a situation where moving veth into network
namespace can drop address on its peer.
 In the first case, I run following command:

yan@...m23:~$ sudo ip netns add foo
yan@...m23:~$ sudo ip link add dev foo type veth peer name Ifoo
yan@...m23:~$ sudo ip link set foo up
yan@...m23:~$ sudo ip addr add 10.1.128.2/31 dev foo
yan@...m23:~$ sudo ip addr show dev foo
437: foo@...o: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UP group default qlen 1000
    link/ether f2:6a:39:d1:2b:75 brd ff:ff:ff:ff:ff:ff
    inet 10.1.128.2/31 scope global foo
       valid_lft forever preferred_lft forever
    inet6 fe80::f06a:39ff:fed1:2b75/64 scope link
       valid_lft forever preferred_lft forever
yan@...m23:~$ sudo ip link set Ifoo netns foo
yan@...m23:~$ sudo ip addr show dev foo
437: foo@...36: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
noqueue state LOWERLAYERDOWN group default qlen 1000
    link/ether f2:6a:39:d1:2b:75 brd ff:ff:ff:ff:ff:ff link-netns foo
    inet6 fe80::f06a:39ff:fed1:2b75/64 scope link
       valid_lft forever preferred_lft forever

If I add address to a veth, it always gets lost after its peer is moved into ns.

Somehow interesting thing is, if I set its peer to "Down" state, then
things seem to be OK!

yan@...m23:~$ sudo ip netns add foo
yan@...m23:~$ sudo ip link add dev foo type veth peer name Ifoo
yan@...m23:~$ sudo ip link set Ifoo down
yan@...m23:~$ sudo ip addr add 10.1.128.2/31 dev foo
yan@...m23:~$ sudo ip addr show dev foo
439: foo@...o: <NO-CARRIER,BROADCAST,MULTICAST,UP,M-DOWN> mtu 1500
qdisc noqueue state LOWERLAYERDOWN group default qlen 1000
    link/ether 3a:94:12:d8:01:30 brd ff:ff:ff:ff:ff:ff
    inet 10.1.128.2/31 scope global foo
       valid_lft forever preferred_lft forever
    inet6 fe80::3894:12ff:fed8:130/64 scope link
       valid_lft forever preferred_lft forever
yan@...m23:~$ sudo ip link set Ifoo netns foo
yan@...m23:~$ sudo ip addr show dev foo
439: foo@...38: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
noqueue state LOWERLAYERDOWN group default qlen 1000
    link/ether 3a:94:12:d8:01:30 brd ff:ff:ff:ff:ff:ff link-netns foo
    inet 10.1.128.2/31 scope global foo
       valid_lft forever preferred_lft forever
    inet6 fe80::3894:12ff:fed8:130/64 scope link
       valid_lft forever preferred_lft forever

The address is still on the device after its peer moved. But if I put
these commands in a shell, then it is not working again:

yan@...m23:~$ cat up.sh
#!/bin/sh -x

ip netns add foo
ip link add dev foo type veth peer name Ifoo
ip link set Ifoo down
ip addr add 10.1.128.2/31 dev foo
ip link set Ifoo netns foo
sleep 1
ip addr show dev foo
yan@...m23:~$ sudo bash up.sh
451: foo@...50: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
noqueue state LOWERLAYERDOWN group default qlen 1000
    link/ether 86:24:e7:5b:d8:f0 brd ff:ff:ff:ff:ff:ff link-netns foo

If I add a "sleep 1" after dev creation, then it seems to be fine again.

Question: what is the expected behavior on a freshly created veth
pair? It seems to me that there is some race condition regarding the
2nd and 3rd case. Is this a known thing, or I accidentally triggered
some buggy path? Can someone help me sort out what is happening in
these cases? I am happy to provide more information if needed.

Thanks!

-- 
Yan