From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=209.85.218.52 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794333638; b=RXIY6+Vqmdb2vz+MY0nHcYrNNOrTjVLK6iFdy7XZogXqQEwOjnZlW/LvN8NgsweQ4TEy csL5ueUmSvTBTYYwI6aHLPdfWCFYLuMH+P0iyyqG3qXFjM/Alk902nhvp2Z2Cgm+8htxw sBD/B15aH7dS6Jab+EgwQnCt5bBhOOhxNm1wioRGWdOKJQ3JLAYuWjeAjc5H7HH8ZdbCE vrkuA2eKHuL3MTcPs2D1hrXM6tygenJC80aAwWRFKoPnjfDa7C6o6APep9mcWhcBeb90I fE9ZqLz7haX4RiIPxOjuPMFLTQWSGZT64I0cXoQ5SIk+XNop7gMLx+cnLYCtdTSyRlg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794333638; h=DMARC-Filter:Received:DKIM-Signature:X-Google-DKIM-Signature: X-Forwarded-Encrypted:X-Gm-Message-State:X-Gm-Gg:X-Received:Received: From:To:Cc:Subject:Date:Message-ID:X-Mailer:In-Reply-To:References: MIME-Version:Content-Type:Content-Transfer-Encoding; bh=9LuItXp5s8cFtxPZ9H5FlDtsQK3I8Ay0nxSYFMAUyVk=; b=pixAwvoTc56VkStGhnRxuZcJp7jtWoDfLGqiFwsu70S/OfIJf3OHh8aH/C7W3vOIYkxt W39cQ7QUUWxZUGti/DFICt7i1X1I+jnz7fHLy0cjhYSwpKC63H8MhPwl6kQSpv0pK3vqE oiLGxVuSrDJdh8CRHtdIpxmQxbja4bv67wU1q/SQ9XgC8PHCmlKoPcHF+pypjARPwMIya C/Dylk9MElKMEpHk0noxOfyheOkqR8zxLa8CNdDbvpVM6hAjWz5LQHfyslKqFRUuC8lmq +j6sXZxFrZVj9vbSTyzYFDDnMV8p+46P9owrwyBSdC0n5zB9ZHcKitor9ZpQ5+4ytrw== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20260707 header.b=QClyyri8; arc=none smtp.remote-ip=209.85.218.52 Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5223E606A332 for ; Tue, 10 Nov 2026 18:00:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 5223E606A332 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20260707 header.b=QClyyri8 Received: by mail-ej1-f52.google.com with SMTP id a640c23a62f3a-c4d427836e9so308081266b.1 for ; Tue, 10 Nov 2026 10:00:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20260707; t=1794333637; x=1794938437; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=9LuItXp5s8cFtxPZ9H5FlDtsQK3I8Ay0nxSYFMAUyVk=; b=QClyyri8MkVapcikBH87n/uuQNzP60fqChANntJ3ziDZdO1/muz3JPTQnI9+dnIWGW krWveAsXgNtJ+6rZO0LBkhP9hiHu+NJrC7r2vqGYszAl+3tUeO+PLdgfkiLw9ZXhNl4v +Ol/vrn6v7ayIWCwZPkFRkx3wn9GN2PgOZMQo1TyXlL16cUteA05D3ZwvDbzruo1XSu3 QSkA4LEljNLQ4Mk/ufyBM1g2NK7Zbw1nwXTFtWoOHcmlYbp/W52VWZND91c7xwZoo1Ad UhO/caV3NrZpsGjh6+kqKbPPdQCLCzCIykR/Jl5Ku+NWwN5VaOTeZBjGVJbeHEZmrP4f tTkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1794333637; x=1794938437; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=9LuItXp5s8cFtxPZ9H5FlDtsQK3I8Ay0nxSYFMAUyVk=; b=wFkCh/pZgM9iWfaYLECgyP1Qd3nsZq1DzHn+lVDxUp6RhX/CYkIBU4BolCw7kI0BmK UUKlUBS/Mm8/OqQ8KLbsjPRcNraQfJxxCKk55hnjd5Ps2ecIc4u8WKsHKuPavtZNg1gm ToC6Bu4ROOMEXOtfEjp0JgoyDoA2Tu+GzhiVhAB9QohmxNb8KjE1RZl4+7OoGGnqIvhr esjK5KFPBAm4W6LU8BqY0FCEZ3ISfwJJcZPMK0Tqim0aWWIhTsWFpKxZ5ZVm3wm+wYHc jg4MYoE5ZFsC2n9cnrws4PGAFnm6XViGDvDHllxBPG5okQ7DALN8zv3SnIYPVFtpXMOb Gk5Q== X-Forwarded-Encrypted: i=1; AL+hErHCHkXWbD5d/kdDCwLzjlB4ir282fQc8DtKOYnrOAjOkYB9GXoaprHLAqGWLdvGcWTMAjPDiqm17CE4Thw=@vger.kernel.org X-Gm-Message-State: APuU4Z9ElEbKkp6DYbGUkLofa/VNOBpwY+bmHwrmKwWmB5n+dmtzxJZi UOdWHG+nQKp2/Cd/EHq6HtITQiYxUURNMjYqgViAluIMbsjiSB6DmhTtl/CElvXM X-Gm-Gg: AYBFou3uPv0L1pjZyg/sBbLG6fInKSStgErqPGHujEUBavDbDiTu8aZszri61JL2iEn WIf/T5sy/yOizKK5oiRZHOmdRCH//vDnObuVKKHZ4sEZpnAaj+wVWdEWiZiE12jyTAYumfYzr30 MZCl75Qg4yHTgF6YfMVubOVnGCWFpgHPdrCejzqyQ2c67p0zvDw2zoNkzfIxPazJ0NSwRgfwNZa 8QLV3Vzw7fwFfwedkbTecFiZ9IqMmWoVX2aRK9PHtdjmjqxvlBtrpdFDnKy0RF9OgG5zbPMmYuP JwKUOdbBJdluyG8USuvKXn6inLriBXIGeNz1069q0dD8NVw//0XYXCIlbd8aSFyFE9LatYR6JCl 3WSXJjzOtPUfF2pQsQ0mvKsKxLTjcKf8KpGwuLsYGAVyMvBtcvTsyIs04OFqrPCQCfN4eMULLDB 00DjcHZWUwgpHsiNfqfiotb8fHalpFsYFJ/ql8DpQn9XucO8+Pb+9t3zehrv+5BjTlzW3tT31eq lUaraFv4gSwNc0bDzrYV9CVY8Rr6V1cUzZG8KFV8W+gqMFhYT2zrdty7rmiIqnZ73LV8WjTLAhR gyW7gtYST/hlzjR1n1mXtV76HtWjFIE2BxIQHj4JhvAo+suI X-Received: by 2002:a17:906:830c:b0:c42:102f:15df with SMTP id a640c23a62f3a-c504951eb29mr193190866b.8.1794333636284; Tue, 10 Nov 2026 10:00:36 -0800 (PST) Received: from Air-pasichndev ([188.163.8.107]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c504a59fd2csm141668066b.44.2026.11.10.10.00.35 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Tue, 10 Nov 2026 10:00:35 -0800 (PST) From: Andrii Pasichnyk To: "Jason A. Donenfeld" Cc: netdev@vger.kernel.org, wireguard@lists.zx2c4.com, Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , linux-kernel@vger.kernel.org Subject: Re: [PATCH net] wireguard: peer: free packets left on the per-peer queues on removal Date: Tue, 10 Nov 2026 20:00:34 +0200 Message-ID: <20261110180034.76136-1-apasichnik9@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: <20261003201625.4572-1-apasichnik9@gmail.com> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Tue, Nov 10, 2026 at 05:37:31PM +0100, Jason A. Donenfeld wrote: > I'd be interested in seeing your adjustment to netns.sh so that I can > test this myself and validate various approaches. Do you have something > really minimal? Also, is this a test case that could be implemented > minimally enough that we could integrate this into netns.sh permanently? Here is a minimal version. It relies on the created/destroyed object check netns.sh already does at the end: diff --git a/tools/testing/selftests/wireguard/netns.sh b/tools/testing/selftests/wireguard/netns.sh index a8f550aec..8303802c0 100755 --- a/tools/testing/selftests/wireguard/netns.sh +++ b/tools/testing/selftests/wireguard/netns.sh @@ -207,6 +207,20 @@ n0 iptables -F INPUT ip1 link set wg0 mtu $orig_mtu ip2 link set wg0 mtu $orig_mtu +# Remove a peer while a UDP flood keeps its receive queue busy, then re-add it; +# packets left on the per-peer queues would keep it from being destroyed, +# which the created/destroyed check at the end catches. +for ((i = 0; i < 10; ++i)); do + n1 iperf3 -s -1 -B 192.168.241.1 & + pids=( $! ); waitiperf $netns1 $! + n2 iperf3 -Z -t 2 -b 0 -u -l 64 -P 4 -c 192.168.241.1 >/dev/null 2>&1 & + pids+=( $! ); sleep 1 + n1 wg set wg0 peer "$pub2" remove + kill "${pids[@]}" 2>/dev/null || true; wait "${pids[@]}" || true + n1 wg set wg0 peer "$pub2" preshared-key <(echo "$psk") allowed-ips 192.168.241.2/32,fd00::2/128 endpoint 127.0.0.1:2 + n1 ping -c 1 -W 1 192.168.241.2 +done + # Test using IPv4 that roaming works ip0 -4 addr del 127.0.0.1/8 dev lo ip0 -4 addr add 127.212.121.99/8 dev lo diff --git a/tools/testing/selftests/wireguard/qemu/kernel.config b/tools/testing/selftests/wireguard/qemu/kernel.config index 368fd9d60..c69a408a5 100644 --- a/tools/testing/selftests/wireguard/qemu/kernel.config +++ b/tools/testing/selftests/wireguard/qemu/kernel.config @@ -67,7 +67,7 @@ CONFIG_SYSCTL=y CONFIG_SYSFS=y CONFIG_TMPFS=y CONFIG_CONSOLE_LOGLEVEL_DEFAULT=15 -CONFIG_LOG_BUF_SHIFT=18 +CONFIG_LOG_BUF_SHIFT=20 CONFIG_PRINTK_TIME=y CONFIG_BLK_DEV_INITRD=y CONFIG_LEGACY_VSYSCALL_NONE=y Two details matter: - The ping after the re-add. Without it the re-added peer has no session while the other side keeps using the old keypair, so nothing flows until the next handshake and only the first removal happens under load. My original reproducer had this flaw, so the "5 in 2140" in the commit message undercounts: most of those removals were idle. - The log buffer. With message_cost=0 each removal under load logs up to ~1000 "Packet has unallowed src IP" lines, which overflow the default 256 KB buffer; the object check then reports false "merely destroyed" errors and can miss real leaks. 1 MB is enough for 10 iterations. Without the kernel.config change, 2 iterations fit in the default buffer, but caught the leak in only 2 of 6 runs. Results on net-next 66974df65a0b, x86 KVM: unpatched, 1 vCPU: failed in all 3 runs; 25-40% of loaded removals leak a peer and its keypair unpatched, 2 vCPUs: failed (1 run) unpatched, 4 vCPUs: passed (1 run) patched, 1 and 4 vCPUs: passed; 0 leaks in 212 loaded removals, including a 200-iteration run A leak shows as "Error: wg0: Peer N: merely created" plus a matching "Keypair M: merely created". One gotcha when switching NR_CPUS: the qemu Makefile does not regenerate the kernel .config, so delete build//kernel/.config first. So yes, I think it can go into netns.sh permanently: 10 iterations add about 13 seconds and caught the bug on every 1-vCPU run of an unpatched kernel. I can send it as a separate patch, or fold it into a v2 of the fix, whichever you prefer. Thanks, Andrii