netdev - [BUG] rtnl_newlink: Rogue MOVE event delivered on netns change

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

Message-ID: <20231010121003.x3yi6fihecewjy4e@House.clients.dxld.at>
Date: Tue, 10 Oct 2023 14:10:03 +0200
From: Daniel Gröber <dxld@...kboxed.org>
To: "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>
Cc: netdev@...r.kernel.org, Richard Weinberger <richard@....at>
Subject: [BUG] rtnl_newlink: Rogue MOVE event delivered on netns change

Hi netdev,

Changing a device's netns and renaming it with one RTM_NEWLINK call causes
a rogue MOVE uevent to be delivered to the new netns in addition to the
expected ADD uevent.

iproute2 reproducer:

    $ ip netns add test
    $ ip link add dev eth0 netns test type dummy
    $ ip link add dev eth0 type dummy

    $ ip -netns test link set dev eth0 netns 1 name eth123

With the last command, which renames the device and moves it out of the
netns, we get the following:

    $ udevadm monitor -k
    KERNEL[230953.424834] add      /devices/virtual/net/eth0 (net)
    KERNEL[230953.424914] move     /devices/virtual/net/eth0 (net)
    KERNEL[230953.425066] move     /devices/virtual/net/eth123 (net)

The problem is the MOVE event hooribly confuses userspace. The particular
symptom we're seing is that systemd will bring down the ifup@...0.service
on the host as it handles the MOVE of eth0->eth123 as a stop for the
BoundTo sys-subsystem-net-devices-eth0.device unit.

I also create a clashing eth0 device on the host in the repro to
demonstrate that the RTM_NETLINK move+rename call is atomic and so the MOVE
event is entirely nonsensical.

Looking at the code in __rtnl_newlink I see do_setlink first calls
__dev_change_net_namespace and then dev_change_name. My guess is the order
is just wrong here.

Thanks,
--Daniel

PS: Full debugging log in https://github.com/lxc/incus/issues/146