All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jun Yang <juny24602@gmail.com>
To: netdev@vger.kernel.org
Cc: Jun Yang <junvyyang@tencent.com>,
	stable@kernel.org, TencentOS Corvus AI <corvus@tencent.com>,
	Jon Maloy <jmaloy@redhat.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Simon Horman <horms@kernel.org>,
	tipc-discussion@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: [PATCH net] tipc: reject name table updates with invalid origin node
Date: Fri, 31 Jul 2026 18:16:37 +0800	[thread overview]
Message-ID: <20260731101657.29119-1-juny24602@gmail.com> (raw)

From: Jun Yang <junvyyang@tencent.com>

tipc_update_nametbl() trusts the origin node carried in a received
NAME_DISTRIBUTOR message. For a WITHDRAWAL it removes and frees the
matching publication with tipc_nametbl_remove_publ() (a {key,ref}
wildcard match that ignores the node), then calls
tipc_node_unsubscribe() to unlink the publication from the advertising
node's publ_list.

tipc_node_unsubscribe() is a no-op when in_own_node(net, node) is true,
and in_own_node() treats node 0 as "own" (addr == own || !addr). So a
WITHDRAWAL with orignode == 0 frees the publication via kfree_rcu()
while the paired unsubscribe silently does nothing, leaving the freed
publication linked on the owning peer's publ_list through its
binding_node.

A subsequent legitimate WITHDRAWAL for a neighbouring publication that
the same peer advertised then performs list_del() across the freed
object, writing a kernel pointer into freed memory (use-after-free
write) and corrupting the live publ_list head. The whole sequence is
attacker-driven from received packets and is reachable by an
unprivileged local user, who can gain CAP_NET_ADMIN in a new network
namespace via unshare(CLONE_NEWUSER|CLONE_NEWNET), enable a TIPC UDP
bearer, and emulate a peer over loopback UDP.

A name table update must always originate from a real peer node, never
from our own address or from node 0. Reject such updates up front:
in_own_node() already covers both cases, so a single guard at the top
of tipc_update_nametbl() drops the malformed update before any
publication is removed or freed.

Fixes: 37922ea4a310 ("tipc: permit overlapping service ranges in name table")
Cc: stable@kernel.org
Reported-by: TencentOS Corvus AI <corvus@tencent.com>
Signed-off-by: Jun Yang <junvyyang@tencent.com>
---
 net/tipc/name_distr.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/tipc/name_distr.c b/net/tipc/name_distr.c
index ba4f4906e13b..a496e2e9ef62 100644
--- a/net/tipc/name_distr.c
+++ b/net/tipc/name_distr.c
@@ -286,6 +286,9 @@ static bool tipc_update_nametbl(struct net *net, struct distr_item *i,
 	u32 key = ntohl(i->key);
 	struct tipc_uaddr ua;
 
+	if (in_own_node(net, node))
+		return false;
+
 	/* A peer-advertised binding with lower > upper can never be matched
 	 * or withdrawn and would leak the publication; the local bind path
 	 * rejects such ranges, so reject ranges learned from the network too.
-- 
2.55.0


                 reply	other threads:[~2026-07-31 10:17 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260731101657.29119-1-juny24602@gmail.com \
    --to=juny24602@gmail.com \
    --cc=corvus@tencent.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=jmaloy@redhat.com \
    --cc=junvyyang@tencent.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=stable@kernel.org \
    --cc=tipc-discussion@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.