From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 31F4D3FFFB8 for ; Fri, 31 Jul 2026 10:17:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785493038; cv=none; b=rr7C13IQ0dP8LjeFdC/8fu4AvDK8mBxM7RFI3udkYB9AZy0QvvAXyRJfmdIXgxZMB3GRZ7I3FT+GX6q6kPd6K87CYT0ec4xEmsDSOxeSy8R1UAwAoJ2AZfAHx3InH8SYgVYlxc5teVb91v4daojrApjztexLQhuSi4z9tcE9nOo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785493038; c=relaxed/simple; bh=zvnzDL5jc91mCpziI/WkXoqIm6A9BOrC0ngqHkuasv0=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=K6FjyPHfBmTn3hCYm/WkEY0Ip3MpBZlLOg0brdt6zZLy3CbFQ6N1O9pORlAvfrDfyZQ5L/8ag1oubcXQjejGqz6HQ3IyW7K62jp52JbJ7UvzxTPPulWe/prgNbsoALwB1IVlKe/s5cJIv7jWy9NKt7y7NZUjEhTGhd7xcwbnR84= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=PdXhqWR+; arc=none smtp.client-ip=209.85.214.171 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.b="PdXhqWR+" Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-2cace91f112so8240975ad.0 for ; Fri, 31 Jul 2026 03:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785493026; x=1786097826; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=jYPlNC3zN2lWfLh36G6tN8zz1VZu57wO9xdzsz1WXLc=; b=PdXhqWR+evCSlfrYoGbA+nNHf2AC+cDOlpLkIMwKs2DxXwe8zfc0FctDcYG5gXm/Eo 6CniObB3V8+taFHxePLDBvIEDmDxr92PVdokDLWUccaCCSj53KNsOgEaR/hNfoyy4uOm Ol/QCWkM3pPNkvQam8yB9dxOLojEJ0NBLbvQJHnNoytRE7A1dmQ+PJ4Df7cxXyvXkfyo FYcRO5K03M3thVVwV89eZREV6yp///TSHcD+juNpQEbdm1jPDal28TYpl9JeQbYok8we xjGuHPlWsc+TR74p45ZjWgO1t9XsKZiz3HyS38Ie++99HewvUXaL/3ba9iVGhKPPdlPN XTDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785493026; x=1786097826; h=content-transfer-encoding:mime-version: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=jYPlNC3zN2lWfLh36G6tN8zz1VZu57wO9xdzsz1WXLc=; b=gO6y20S79lnkGhcZXdO321v2oKqlR/emu0Dz3cJnOwh16S6fswopbSU5tVWjRO/C++ KKgI4XnTokAjcW47SSjiuBJkIuSfobBtylLknk89ibmkr0FkpIs10bMCGBAm0JK9Qf/x ZhSPr08dzUf2d6oTIy/7Nm9q9nAYx28fuk4Jqw8h6o0QeB46aaOJeVW8LA6EQLMHI9gc RJIL2YiUYGvcdpqJwIYF6OwVGGxAsbRvLG6KMETha4VaJ4Z37MaZyvRE2AY/9sBVllUS 56lpEaE646Q09TEHpCtmQtgChpzkSJy02UDvS+esl3gAGWYpXBdPjjEggjuXwo4KB1NN 7tLw== X-Forwarded-Encrypted: i=1; AHgh+Rql/k/gfWa2GkaXFhGSAG5fe++7BemXSQf6feD6Qn9sItxqTayYLMf0bHFQWket4olGSV6n68b14ButqvM=@vger.kernel.org X-Gm-Message-State: AOJu0YzlxIOvNXy/a5ra2fxzUtK4Jnp8+KbQqUvUuPlQJmTBJlkehkM2 d65/pQZeShKXQV6fzrN/FiT11x9xyRFHQaDXs8Czd/Bj0AF66XBIvffq X-Gm-Gg: AR+sD10tn3Lrw2mOgueBmw7bq+XcmRd3eZHw/qeWUlWtTCYWh3zxLmSceWE2/XCrUPX WqCu2aXPnLzplZ0TVqmqMpTHiMlwQhT/60tkHBwX+5jSReFbBlWbjRred2nyehK49k1zjds1b+n mwO4YF/I6wONcZNbzzM8+zl6FPOKPHOQMgToOUuiZC19l9vvjYaYr9uAPFD9R/F/O0jZaKSWikE UlngBUcGKG4QIQE4zcB/srsFZ4zdUf/1ju6OfvGkmp1W8HiWh2KFEI0kXNMK9Dl+HPdJgJbmGir t3DFUzroK7yLmnM9sQ8lpsgfXT9reF/v3SnzKSfyhNaPLLzAzIzvW4vOnzlWj7/UfnstBEppKaM vxd2LJ8bOirPWBh8fIDW30IciFMIo5cSgl7YVga5fDjXyzmrRgv1IHrD40Hvfi/q3q3bp84txs8 ncFVrxEpvc3/Dz/Mrmz2dBvH38VPHdQNYzbrHBjLjgM3r2Nqef3A8u2MANkUwY0XMYgeGswXVfi 1iHRPZB8LS++pbfkULaBqcCzDE= X-Received: by 2002:a17:903:1968:b0:2cc:a853:1311 with SMTP id d9443c01a7336-2d046ef0be8mr14436195ad.47.1785493026001; Fri, 31 Jul 2026 03:17:06 -0700 (PDT) Received: from JUNVYYANG-MC1.tencent.com ([43.132.141.25]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2d04b15db1esm3436485ad.81.2026.07.31.03.17.03 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Fri, 31 Jul 2026 03:17:05 -0700 (PDT) From: Jun Yang To: netdev@vger.kernel.org Cc: Jun Yang , stable@kernel.org, TencentOS Corvus AI , Jon Maloy , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , 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 Message-ID: <20260731101657.29119-1-juny24602@gmail.com> X-Mailer: git-send-email 2.50.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Jun Yang 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 Signed-off-by: Jun Yang --- 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