From: Cen Zhang <zzzccc427@gmail.com>
To: matttbe@kernel.org, martineau@kernel.org, davem@davemloft.net,
edumazet@kernel.org, kuba@kernel.org, pabeni@redhat.com
Cc: geliang@kernel.org, horms@kernel.org, netdev@vger.kernel.org,
mptcp@lists.linux.dev, linux-kernel@vger.kernel.org,
baijiaju1990@gmail.com, jjzuming@gmail.com, zzzccc427@gmail.com
Subject: [PATCH net v2] mptcp: protect listener backlog reads in diagnostics
Date: Mon, 26 Oct 2026 22:48:16 +0800 [thread overview]
Message-ID: <pm-mptcp-objects-candidate-0066-v5-4d1b83d62fcde2d57e8d@gmail.com> (raw)
mptcp_diag_get_info() reports the accept queue of a listening MPTCP
socket by reading msk->first. The token based dump and the exact token
query only hold a reference on the MPTCP socket, which pins neither the
first subflow nor the listener hash bucket, and __mptcp_close_ssk()
drops the last reference on the first subflow before clearing
msk->first.
An application can disconnect a connected MPTCP socket with AF_UNSPEC,
which removes the token but retains the first subflow, listen on it
again and close it. A dump that obtained the MPTCP socket before the
disconnect then reads the backlog of a freed TCP listener:
Token diagnostic Application
mptcp_token_iter_next()
retain MPTCP socket
connect(AF_UNSPEC)
remove token, retain first
listen()
reuse first
mptcp_diag_get_info()
observe TCP_LISTEN
lsk = msk->first
close()
mptcp_destroy()
__mptcp_close_ssk()
release first
read lsk->sk_ack_backlog
The report below was decoded with scripts/decode_stacktrace.sh against
the 7.2.0-rc5 based test kernel that produced it, with the line numbers
mapped to this tree; only the relevant frames are kept:
BUG: KASAN: slab-use-after-free in mptcp_diag_get_info (net/mptcp/mptcp_diag.c:209)
Read of size 4 at addr ffff888111763818 by task python3/499
Call Trace:
mptcp_diag_get_info (net/mptcp/mptcp_diag.c:209)
inet_sk_diag_fill (net/ipv4/inet_diag.c:330)
mptcp_diag_dump (net/mptcp/mptcp_diag.c:23 net/mptcp/mptcp_diag.c:177)
__inet_diag_dump (net/ipv4/inet_diag.c:823)
netlink_dump (net/netlink/af_netlink.c:2351)
Allocated by task 497:
sk_alloc (net/core/sock.c:2337)
inet_create (net/ipv4/af_inet.c:333)
__sock_create (net/socket.c:1679)
mptcp_subflow_create_socket (net/mptcp/subflow.c:1836)
__mptcp_nmpc_sk (net/mptcp/protocol.c:111 net/mptcp/protocol.c:143)
mptcp_setsockopt (net/mptcp/sockopt.c:313 net/mptcp/sockopt.c:916)
Freed by task 0:
slab_free_after_rcu_debug (mm/slub.c:6571)
rcu_core (kernel/rcu/tree.c:2919)
Second to last potentially related work creation:
__call_rcu_common.constprop.0 (kernel/rcu/tree.c:3287)
sk_destruct (net/core/sock.c:2446)
__sk_free (net/core/sock.c:2459)
sk_free (net/core/sock.c:2470)
__mptcp_close_ssk (include/net/sock.h:2024 net/mptcp/protocol.c:2721)
mptcp_destroy_common (net/mptcp/protocol.c:3579)
mptcp_destroy (net/mptcp/protocol.c:3815)
__mptcp_destroy_sock (net/mptcp/protocol.c:3421)
__mptcp_close (net/mptcp/protocol.c:3523)
mptcp_close (net/mptcp/protocol.c:3538)
inet_release (net/ipv4/af_inet.c:442)
The first subflow is a TCP socket: TCP listeners carry SOCK_RCU_FREE
and tcp_prot/tcpv6_prot sockets live in SLAB_TYPESAFE_BY_RCU caches, so
reading the two backlog counters under rcu_read_lock() is safe, and a
stale value is acceptable for diagnostics. mptcp_diag_dump_listeners()
already runs the formatter inside an RCU read-side section; only the
token dump and mptcp_diag_dump_one() reach it without one. Take
rcu_read_lock() around the msk->first snapshot and the backlog reads.
Fixes: 4fa39b701ce9 ("mptcp: listen diag dump support")
Suggested-by: Eric Dumazet <edumazet@kernel.org>
Signed-off-by: Cen Zhang <zzzccc427@gmail.com>
Assisted-by: LLM
---
Changes in v2:
- Take rcu_read_lock() around the first subflow reads instead of the MPTCP
data lock plus an owner check, as suggested by Eric Dumazet; this avoids
the new msk slock -> listener hash lock nesting and keeps ss reporting the
accept queue while the socket is owned.
- Decode the stack trace with scripts/decode_stacktrace.sh, map the line
numbers to this tree and keep only the relevant frames.
Link to v1: https://lore.kernel.org/r/pm-mptcp-objects-candidate-0066-v3-73df72b7a543d4cada0e@gmail.com
net/mptcp/mptcp_diag.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/mptcp/mptcp_diag.c b/net/mptcp/mptcp_diag.c
index 136c2d05c0ee..28a42eee6651 100644
--- a/net/mptcp/mptcp_diag.c
+++ b/net/mptcp/mptcp_diag.c
@@ -200,8 +200,10 @@ static void mptcp_diag_get_info(struct sock *sk, struct inet_diag_msg *r,
r->idiag_wqueue = sk_wmem_alloc_get(sk);
if (inet_sk_state_load(sk) == TCP_LISTEN) {
- struct sock *lsk = READ_ONCE(msk->first);
+ struct sock *lsk;
+ rcu_read_lock();
+ lsk = READ_ONCE(msk->first);
if (lsk) {
/* override with settings from tcp listener,
* so Send-Q will show accept queue.
@@ -209,6 +211,7 @@ static void mptcp_diag_get_info(struct sock *sk, struct inet_diag_msg *r,
r->idiag_rqueue = READ_ONCE(lsk->sk_ack_backlog);
r->idiag_wqueue = READ_ONCE(lsk->sk_max_ack_backlog);
}
+ rcu_read_unlock();
}
if (!info)
next reply other threads:[~2026-10-26 14:48 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-26 14:48 Cen Zhang [this message]
2026-10-26 14:50 ` netdev-bot+sinfo
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=pm-mptcp-objects-candidate-0066-v5-4d1b83d62fcde2d57e8d@gmail.com \
--to=zzzccc427@gmail.com \
--cc=baijiaju1990@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=geliang@kernel.org \
--cc=horms@kernel.org \
--cc=jjzuming@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martineau@kernel.org \
--cc=matttbe@kernel.org \
--cc=mptcp@lists.linux.dev \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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
all inboxes | Powered by JetHome®