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 5122C3C3F4C; Thu, 30 Jul 2026 14:52:51 +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=1785423172; cv=none; b=R8c7aa21/ohBL6KSFYUPFeqiAdpZJFGfrcBHfIYj35e+uSjyFkG0JZsHESdJsrDzWmPygDMv74r8MpVh6uxWPm7cUiKmNkY5aaJ4olBZ2ZrnOM5kSccN0MP8GOclHv6EEiWps5AFgR3SXQdAHudtocHWIKxZkTFNSgyvXnmyDs0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785423172; c=relaxed/simple; bh=B8OwLB0O31d+tHfyt6g0siZ/PTqaSP8QJBL9Xuekaj0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=pjHEY7a1mToOQzvSW1c1p/90u2avBsTrvHcg0toPoJF3qX+CHB5V5DiJSKfBQBMtO+eYkyFFDt6EvC0O4hPLI7gTnn/t4tY7ZVyE5MX1BU11HqpbwL1iYvCa1rzzvapBKNQ0uqxMRYwJsNEwF1dEnfmZoOjZWH9HfZV5b7aOb6I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=mVkGIIPU; 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="mVkGIIPU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A76F21F000E9; Thu, 30 Jul 2026 14:52:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1785423171; bh=+zFKGPu3oUBwiNUX1zlO+yDVFN4e5SefwPsAFwAd6e0=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=mVkGIIPUADRGwoBT5b9BVtst8VerhdXjt00K941uPU0SVenoL2gJRRkDSXwf6BADe PI5aHP7ob+QN0wa3bc1d0MQuHIesoNqcemWtQqq5lBLYkle6BMY7SyUa7sD4ddEjjM NekN+mr7p8v3XGUNpDNdAE2BGhidkFgQOX30OCOE= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Tung Nguyen , Breno Leitao , Daehyeon Ko <4ncienth@gmail.com>, Simon Horman , Paolo Abeni Subject: [PATCH 7.1 689/744] tipc: clear sock->sk on the failed-insert path in tipc_sk_create() Date: Thu, 30 Jul 2026 16:16:02 +0200 Message-ID: <20260730141458.910028708@linuxfoundation.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260730141444.267951807@linuxfoundation.org> References: <20260730141444.267951807@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 7.1-stable review patch. If anyone has any objections, please let me know. ------------------ From: Daehyeon Ko <4ncienth@gmail.com> commit ba0533fc163f905fe817cfabdf8ed4058da44800 upstream. When tipc_sk_create() fails to insert the new socket (tipc_sk_insert() returns non-zero), its error path frees the sk with sk_free() but leaves sock->sk pointing at the freed object: if (tipc_sk_insert(tsk)) { sk_free(sk); pr_warn("Socket create failed; port number exhausted\n"); return -EINVAL; } This is harmless for plain socket(): the syscall layer clears sock->ops before releasing, so tipc_release() is never called. It is not harmless on the accept() path. tipc_accept() creates the pre-allocated child socket with tipc_sk_create(net, new_sock, 0, kern); on failure it leaves new_sock->sk dangling and new_sock->ops non-NULL, and do_accept() then fput()s the new file, so __sock_release() -> tipc_release() runs lock_sock(new_sock->sk) on the freed sk -- a use-after-free write of the sk_lock spinlock. tipc_release() already guards this exact "failed accept() releases a pre-allocated child" case with "if (sk == NULL) return 0;", but the guard is bypassed because tipc_sk_create() left sock->sk non-NULL (dangling) rather than NULL. Clear sock->sk on the failed-insert path so the existing tipc_release() NULL check fires and the use-after-free is avoided. The tipc_sk_insert() failure is reached when the per-netns socket rhashtable hits its max_size (tsk_rht_params.max_size = 1048576, ~2M elements) -- i.e. once a netns holds ~2M TIPC sockets every insert returns -E2BIG. BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839) Write of size 8 at addr ffff8880047cdc38 by task init/1 lock_sock_nested (net/core/sock.c:3839) tipc_release (net/tipc/socket.c:638) __sock_release (net/socket.c:710) sock_close (net/socket.c:1501) __fput (fs/file_table.c:512) Allocated by task 1: sk_alloc (net/core/sock.c:2308) tipc_sk_create (net/tipc/socket.c:487) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034) Freed by task 1: __sk_destruct (net/core/sock.c:2391) tipc_sk_create (net/tipc/socket.c:504) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034) Fixes: 00aff3590fc0 ("net: tipc: fix possible refcount leak in tipc_sk_create()") Cc: stable@vger.kernel.org Reviewed-by: Tung Nguyen Reviewed-by: Breno Leitao Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260714131939.1255974-1-4ncienth@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman --- net/tipc/socket.c | 1 + 1 file changed, 1 insertion(+) --- a/net/tipc/socket.c +++ b/net/tipc/socket.c @@ -501,6 +501,7 @@ static int tipc_sk_create(struct net *ne tipc_set_sk_state(sk, TIPC_OPEN); if (tipc_sk_insert(tsk)) { sk_free(sk); + sock->sk = NULL; pr_warn("Socket create failed; port number exhausted\n"); return -EINVAL; }