bind_wildcard picks an ephemeral port by binding fd[0] with port 0, reads it back with getsockname(), and then reuses that exact port number for the other addresses/families in fd[1..7]. This all happens in the default network namespace, so unrelated processes on the same host are drawing from the very same ephemeral port range (net.ipv4.ip_local_port_range) at the same time.
Such a process can independently get assigned that exact port number on a different, non-conflicting address in the short window between fd[0]'s bind() and fd[1]'s, making fd[1]'s bind() fail with EADDRINUSE for reasons that have nothing to do with the wildcard-bind behavior under test, e.g.: # bind_wildcard.c:775:plain:Expected ret (-1) == 0 (0) # plain: Test terminated by assertion not ok N bind_wildcard.v6_local_v4_local.plain Fix it the same way so_incoming_cpu.c, tcp_port_share.c and reuseport_dualstack.c already do: unshare into a fresh network namespace and bring lo up, so there is nobody else to race with for the port. Signed-off-by: Ricardo B. Marlière (SUSE) <[email protected]> --- tools/testing/selftests/net/bind_wildcard.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/tools/testing/selftests/net/bind_wildcard.c b/tools/testing/selftests/net/bind_wildcard.c index 7d11548b2c61..be3298c791b2 100644 --- a/tools/testing/selftests/net/bind_wildcard.c +++ b/tools/testing/selftests/net/bind_wildcard.c @@ -1,6 +1,8 @@ // SPDX-License-Identifier: GPL-2.0 /* Copyright Amazon.com Inc. or its affiliates. */ +#define _GNU_SOURCE +#include <sched.h> #include <sys/socket.h> #include <netinet/in.h> @@ -716,6 +718,9 @@ static void setup_addr(FIXTURE_DATA(bind_wildcard) *self, int i, FIXTURE_SETUP(bind_wildcard) { + ASSERT_EQ(unshare(CLONE_NEWNET), 0); + ASSERT_EQ(system("ip link set lo up"), 0); + setup_addr(self, 0, variant->family[0], variant->addr[0]); setup_addr(self, 1, variant->family[1], variant->addr[1]); --- base-commit: 1376afc7660bad2a1a5ee0876898312a486cf8bd change-id: 20260901-selftests-net-bind_wildcard_race-c0067a2dc308 Best regards, -- Ricardo B. Marlière (SUSE) <[email protected]>
