[PATCH net v2] tipc: reject name table updates with invalid origin node

[Jun Yang <juny24602@gmail.com>]

From: Jun Yang <junvyyang@tencent.com>

tipc_rcv() locates the sending peer using msg_prevnode(), while
tipc_named_rcv() takes the node address for NAME_DISTRIBUTOR updates
from msg_orignode(). These are separate fields in the message header,
so finding a valid peer does not validate the origin node.

For a WITHDRAWAL with origin node 0, tipc_nametbl_remove_publ() treats
the node as a wildcard and can remove a matching peer publication from
the name table. tipc_node_unsubscribe() then returns without unlinking
binding_node because in_own_node() treats node 0 as local.
tipc_update_nametbl() subsequently calls kfree_rcu(), leaving its
binding_node linked on the peer's publ_list.

Once the publication has been freed, withdrawing an adjacent publication
from the same peer can access the stale list entry in list_del_init().
The following KASAN report shows this access in the list validation code:

  BUG: KASAN: slab-use-after-free in __list_del_entry_valid_or_report
  Read of size 8 at addr ffff8880249c7120 by task a.out/9456

  CPU: 0 UID: 0 PID: 9456 Comm: a.out Not tainted
  7.3.0-rc4-00385-ga7bfaba4823e #81 PREEMPT(full)

  Call Trace:
   <IRQ>
   dump_stack_lvl lib/dump_stack.c:122
   print_address_description mm/kasan/report.c:379 [inline]
   print_report mm/kasan/report.c:482
   kasan_report mm/kasan/report.c:597
   __list_del_entry_valid_or_report lib/list_debug.c:62
   __list_del_entry include/linux/list.h:261 [inline]
   list_del_init include/linux/list.h:333 [inline]
   tipc_node_unsubscribe net/tipc/node.c:687
   tipc_update_nametbl net/tipc/name_distr.c:311 [inline]
   tipc_named_rcv net/tipc/name_distr.c:389
   tipc_rcv net/tipc/node.c:2202
   tipc_udp_recv net/tipc/udp_media.c:390
   udp_queue_rcv_one_skb net/ipv4/udp.c:2433
   udp_queue_rcv_skb net/ipv4/udp.c:2472
   udp_unicast_rcv_skb net/ipv4/udp.c:2625
   udp_rcv net/ipv4/udp.c:2697

Reject zero and own-node origin addresses at the start of
tipc_update_nametbl(), before inserting or removing any publication.
Neither value is a valid origin for a peer name-table update, and
in_own_node() covers both cases.

Fixes: 218527fe27ad ("tipc: replace name table service range array with rb tree")
Cc: stable@vger.kernel.org
Reported-by: TencentOS Corvus AI <corvus@tencent.com>
Assisted-by: tencentos-corvus-ai:hy4-preview
Signed-off-by: Jun Yang <junvyyang@tencent.com>
---
v2:
- Explain the distinction between the sending peer and the origin node.
- Correct the Fixes tag to the commit introducing the node-zero wildcard.
- Link to v1: https://lore.kernel.org/netdev/20260731101657.29119-1-juny24602@gmail.com/
- Review: https://lore.kernel.org/netdev/GV1P189MB19887144315DA4A6AF16FE02C6D52@GV1P189MB1988.EURP189.PROD.OUTLOOK.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.54.0 (Apple Git-157)