From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1CCE24071DA; Sun, 7 Jun 2026 10:16:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780827414; cv=none; b=DvOiZMVKRgXj18b38s3Gt+ecc4SsDVZk4hIAEQfuTIKS2MiTehHQCpR1GBfzNMJ1Jd2WrzW/G2I0q8HpA4umzaF7ba3C9VViCaS3L+oh+L4I5WCIMe1WGSs4itPktdE8UL8MFnEuK6jJ3POxXpS30Jzij0MaEVxl0E8kEMGq9cQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780827414; c=relaxed/simple; bh=L+lsTcOeK05CussPSkt8RQaHZT7fs91kdaaW3LOVv7c=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Lt/Mg1yGocUsbHLP+FLgW0VeiffKydK84UNFM9wm51ACFNQbtdbr5LA5hlsPDWp/LvB2z+CiRpcNwEU8G2g356PCQp/hpHmsICBWV2DfKOaTdYBw2zAA9Brh7c+koK7jqL77hWy/2nsDDOXqw5s1DpoUqctziIvM+IAVRT9PgWo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=V91AD8ED; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="V91AD8ED" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5947F1F00893; Sun, 7 Jun 2026 10:16:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1780827413; bh=GwsU0zCTzSxO7RY1OG8k8B0w4sISqLv9vYgPoEQl+QM=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=V91AD8ED4kui102uOcjn24XteUT4LIVSjr8hIh0qDu8t16Fe0y/dAa0a8TQGVhPWF 7tr8QzxkVmeORZllHqurI+vx+BGuAw8XXCCcLHu3RUmYwFnvZo2TSrZg/XccCaCYpU 74xkGW3A+eZ8WAFP3g132ktDddRv7qo0TZdsQdGA= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Matteo Perin , Ilya Maximets , Nicolas Dichtel , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.12 038/307] net: netlink: dont set nsid on local notifications Date: Sun, 7 Jun 2026 11:57:15 +0200 Message-ID: <20260607095729.088685752@linuxfoundation.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260607095727.647295505@linuxfoundation.org> References: <20260607095727.647295505@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.12-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ilya Maximets [ Upstream commit 88b126b39f9757e9debc322d4679239e9af089c7 ] In most cases, notifications on sockets with NETLINK_LISTEN_ALL_NSID do not contain NSID in their ancillary data in case the event is local to the listener. However, when a self-referential NSID is allocated for a namespace, every local notification starts sending this ID to the user space. This is problematic, because the listener cannot tell if those notifications are local or not anymore without making extra requests to figure out if the provided NSID is local or not. The listener can also not figure out the local NSID beforehand as it can be allocated at any point in time by other processes, changing the structure of the future notifications for everyone. The value is practically not useful, since it's the namespace's own ID that the application has to obtain from other sources in order to figure out if it's the same or not. So, for the application it's just an extra busy work with no benefits. Moreover, applications that do not know about this quirk may be mishandling notifications with NSID set as notifications from remote namespaces. This is the case for ovs-vswitchd and the iproute2's 'ip monitor' that stops printing 'current' and starts printing the nsid number mid-session. Lack of clear documentation for this behavior is also not helping. A search though open-source projects doesn't reveal any projects that use NETNSA_NSID_NOT_ASSIGNED and rely on metadata to contain self-referential NSIDs (expected, since the value is not useful). Quite the opposite, as already mentioned, there are few applications that rely on NSID to not be present in local events. Since the value is not useful and actively harmful in some cases, let's not report it for local events, making the notifications more consistent. Also adding some blank lines for readability. Fixes: 59324cf35aba ("netlink: allow to listen "all" netns") Reported-by: Matteo Perin Signed-off-by: Ilya Maximets Acked-by: Nicolas Dichtel Link: https://patch.msgid.link/20260520172317.175168-3-i.maximets@ovn.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin --- net/netlink/af_netlink.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c index 287b4f921c607e..e250d4a3d03097 100644 --- a/net/netlink/af_netlink.c +++ b/net/netlink/af_netlink.c @@ -1477,10 +1477,14 @@ static void do_one_broadcast(struct sock *sk, p->skb2 = NULL; goto out; } + NETLINK_CB(p->skb2).nsid_is_set = false; - NETLINK_CB(p->skb2).nsid = peernet2id(sock_net(sk), p->net); - if (NETLINK_CB(p->skb2).nsid != NETNSA_NSID_NOT_ASSIGNED) - NETLINK_CB(p->skb2).nsid_is_set = true; + if (!net_eq(sock_net(sk), p->net)) { + NETLINK_CB(p->skb2).nsid = peernet2id(sock_net(sk), p->net); + if (NETLINK_CB(p->skb2).nsid != NETNSA_NSID_NOT_ASSIGNED) + NETLINK_CB(p->skb2).nsid_is_set = true; + } + val = netlink_broadcast_deliver(sk, p->skb2); if (val < 0) { netlink_overrun(sk); -- 2.53.0