From: Jun Yang <juny24602@gmail.com>
To: netdev@vger.kernel.org
Cc: Jon Maloy <jmaloy@redhat.com>,
Tung Quang Nguyen <tung.quang.nguyen@est.tech>,
"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>,
Ying Xue <ying.xue@windriver.com>,
Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>,
tipc-discussion@lists.sourceforge.net,
Jun Yang <junvyyang@tencent.com>,
stable@kernel.org, TencentOS Corvus AI <corvus@tencent.com>
Subject: [PATCH net v2] tipc: purge cong_links under the socket lock in tipc_release()
Date: Wed, 2 Sep 2026 19:18:37 +0800 [thread overview]
Message-ID: <20260902111847.79955-1-juny24602@gmail.com> (raw)
From: Jun Yang <junvyyang@tencent.com>
tipc_release() frees the elements of tsk->cong_links after release_sock(),
i.e. with no lock held:
tipc_sk_remove(tsk);
sock_orphan(sk);
release_sock(sk);
tipc_dest_list_purge(&tsk->cong_links); /* no lock */
tsk->cong_link_cnt = 0;
Every other accessor of that list runs under the socket lock, including
the SOCK_WAKEUP handler in tipc_sk_proto_rcv(), which does
tipc_dest_del(&tsk->cong_links, ...) while holding only sk->sk_lock.slock
via tipc_sk_rcv()'s spin_trylock_bh(). Because the purge never acquires
that spinlock, it provides no mutual exclusion against the wakeup path.
A SOCK_WAKEUP delivered for this port can therefore run concurrently with
the purge: tipc_sk_rcv() looks the socket up and takes a reference before
tipc_sk_remove() unhashes it, is then delayed past release_sock() so
sock_owned_by_user() is false, its spin_trylock_bh() succeeds, and it
list_del()s and kfree()s a struct tipc_dest that the closing task is
walking at the same time. Both paths free entries of the same list.
__tipc_shutdown() does not close this window: it waits on
!tsk->cong_link_cnt but ignores the return value of tipc_wait_for_cond(),
which returns early on timeout, on a pending signal, or on sk_err, so the
close can proceed with cong_links still populated.
BUG: KASAN: slab-use-after-free in
__list_del_entry_valid_or_report (lib/list_debug.c:49)
Read of size 8 at addr ffff888028b4b6c8 by task poc_cong_race/9425
__list_del_entry_valid_or_report (lib/list_debug.c:49)
tipc_dest_list_purge (net/tipc/name_table.c:1225)
tipc_release (net/tipc/socket.c:653)
__sock_release (net/socket.c:735)
sock_close (net/socket.c:1526)
__x64_sys_close (fs/open.c:1560)
Allocated by task 9425:
tipc_dest_push (net/tipc/name_table.c:1183)
__tipc_sendmsg (net/tipc/socket.c:1518)
Freed by task 9418:
kfree (mm/slub.c:6792)
tipc_dest_del (net/tipc/name_table.c:1216)
tipc_sk_filter_rcv (net/tipc/socket.c:2164)
tipc_sk_rcv (net/tipc/socket.c:2450)
tipc_rcv (net/tipc/node.c:2210)
tipc_udp_recv (net/tipc/udp_media.c:389)
kmalloc-32, freed 32-byte region [ffff888028b4b6c0, ffff888028b4b6e0)
Oops: general protection fault, probably for non-canonical address
0xe0347c4420000499
Kernel panic - not syncing: Fatal exception
Move the purge above release_sock() so it runs under the socket lock, the
same discipline commit 844cf763fba6 ("tipc: make macro tipc_wait_for_cond()
smp safe") established for the wait condition. A concurrent tipc_sk_rcv()
then either backlogs the wakeup because the socket is owned, or processes
it against an already empty list, and no new delivery can arrive because
tipc_sk_remove() has already unhashed the socket. tsk->cong_link_cnt is
left where it is, so a wakeup taken from the backlog by release_sock()
still decrements the real count.
Fixes: 365ad353c256 ("tipc: reduce risk of user starvation during link congestion")
Cc: stable@kernel.org
Reported-by: TencentOS Corvus AI <corvus@tencent.com>
Assisted-by: tencentos-corvus-ai:hy4
Signed-off-by: Jun Yang <junvyyang@tencent.com>
---
A KASAN reproducer for this issue is available if requested.
v2:
- Move only the purge. v1 moved "tsk->cong_link_cnt = 0" above
release_sock() as well, which makes a SOCK_WAKEUP taken from the backlog
by release_sock() decrement an already-zeroed u16 down to 65535. The
value is dead by then, but the race does not need that hunk.
v1: https://lore.kernel.org/netdev/20260731101926.31514-1-juny24602@gmail.com/
net/tipc/socket.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index d5d70eb230b5..cf7ee31638ab 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -647,10 +647,14 @@ static int tipc_release(struct socket *sock)
sk_stop_timer(sk, &sk->sk_timer);
tipc_sk_remove(tsk);
+ /* Purge under the socket lock: a SOCK_WAKEUP looked up before
+ * tipc_sk_remove() can still reach tipc_dest_del() on this list.
+ */
+ tipc_dest_list_purge(&tsk->cong_links);
+
sock_orphan(sk);
/* Reject any messages that accumulated in backlog queue */
release_sock(sk);
- tipc_dest_list_purge(&tsk->cong_links);
tsk->cong_link_cnt = 0;
call_rcu(&tsk->rcu, tipc_sk_callback);
sock->sk = NULL;
--
2.55.0
next reply other threads:[~2026-09-02 11:19 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 11:18 Jun Yang [this message]
2026-09-04 11:20 ` [PATCH net v2] tipc: purge cong_links under the socket lock in tipc_release() netdev-bot+sashiko
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=20260902111847.79955-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=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=parthasarathy.bhuvaragan@ericsson.com \
--cc=stable@kernel.org \
--cc=tipc-discussion@lists.sourceforge.net \
--cc=tung.quang.nguyen@est.tech \
--cc=ying.xue@windriver.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox