netdev - veth0 weirdness

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: <20231204165059.089f743c@hermes.local>
Date: Mon, 4 Dec 2023 16:50:59 -0800
From: Stephen Hemminger <stephen@...workplumber.org>
To: netdev@...r.kernel.org
Subject: veth0 weirdness

Discovered an anomoly while exploring using veth for some testing scenarios.

The following will always fail with EEXIST:
# ip li add dev veth0 type veth
RTNETLINK answers: File exists

The reason is that name for the peer is always created first via:
"veth%d" and that will return "veth0". Then when the requested device
is created it will conflict with itself.

Not a big problem, but may confuse users. Fixing it would involve some more
complex transactional logic to create the primary device first then
create the peer which could get messy and likely buggy on first versions
for all the cases.