* Re: [PATCH net] mptcp: protect listener backlog reads in diagnostics
2026-10-26 12:04 [PATCH net] mptcp: protect listener backlog reads in diagnostics Cen Zhang
@ 2026-10-26 12:10 ` netdev-bot+sinfo
2026-10-26 12:38 ` Eric Dumazet
2026-10-30 12:31 ` netdev-bot+sashiko
2 siblings, 0 replies; 5+ messages in thread
From: netdev-bot+sinfo @ 2026-10-26 12:10 UTC (permalink / raw)
To: Cen Zhang
Cc: matttbe, martineau, davem, edumazet, kuba, pabeni, geliang,
horms, netdev, mptcp, linux-kernel, baijiaju1990, jjzuming
Hi!
This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:
- How the issue was discovered, e.g. hit in production, hit during
development, syzbot report, manual code inspection, LLM or static
analysis tool scan.
Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.
The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH net] mptcp: protect listener backlog reads in diagnostics
2026-10-26 12:04 [PATCH net] mptcp: protect listener backlog reads in diagnostics Cen Zhang
2026-10-26 12:10 ` netdev-bot+sinfo
@ 2026-10-26 12:38 ` Eric Dumazet
2026-10-26 14:44 ` Cen Zhang
2026-10-30 12:31 ` netdev-bot+sashiko
2 siblings, 1 reply; 5+ messages in thread
From: Eric Dumazet @ 2026-10-26 12:38 UTC (permalink / raw)
To: Cen Zhang
Cc: matttbe, martineau, davem, kuba, pabeni, geliang, horms, netdev,
mptcp, linux-kernel, baijiaju1990, jjzuming
Le lun. 26 oct. 2026 à 13:04, Cen Zhang <zzzccc427@gmail.com> a écrit :
>
> 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
>
> Take the MPTCP data lock around the listener state check and the
> backlog reads, and only follow msk->first while no process owns the
> socket. Every path that disposes of the first subflow runs with the
> socket owned, and lock_sock() has to take the same spinlock to become
> the owner, so the reads cannot overlap with the release. Waiting for
> the owner is not an option: mptcp_diag_dump_listeners() calls this
> function with the listener hash bucket lock held, which the owner needs
> to unhash that very listener. While a process owns the socket, the dump
> reports the MPTCP socket's own queue values instead.
>
> BUG: KASAN: slab-use-after-free in mptcp_diag_get_info+0x415/0x490
> Read of size 4 at addr ffff888111763818 by task python3/499
>
> Call Trace:
Adding these stack traces without symbols is not really nice.
Time to use scripts/decode_stacktrace.sh
>
> Fixes: 4fa39b701ce9 ("mptcp: listen diag dump support")
> Signed-off-by: Cen Zhang <zzzccc427@gmail.com>
> Assisted-by: LLM
> ---
> net/mptcp/mptcp_diag.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/net/mptcp/mptcp_diag.c b/net/mptcp/mptcp_diag.c
> index 136c2d05c0ee..a71bcaee15c8 100644
> --- a/net/mptcp/mptcp_diag.c
> +++ b/net/mptcp/mptcp_diag.c
> @@ -199,7 +199,12 @@ static void mptcp_diag_get_info(struct sock *sk, struct inet_diag_msg *r,
> READ_ONCE(mptcp_sk(sk)->backlog_len);
> r->idiag_wqueue = sk_wmem_alloc_get(sk);
>
> - if (inet_sk_state_load(sk) == TCP_LISTEN) {
> + /* The listener walk holds the listen hash lock: do not wait for a
> + * socket owner that could be unhashing the first subflow.
> + */
> + mptcp_data_lock(sk);
> + if (!sock_owned_by_user(sk) &&
> + inet_sk_state_load(sk) == TCP_LISTEN) {
> struct sock *lsk = READ_ONCE(msk->first);
>
> if (lsk) {
> @@ -210,6 +215,7 @@ static void mptcp_diag_get_info(struct sock *sk, struct inet_diag_msg *r,
> r->idiag_wqueue = READ_ONCE(lsk->sk_max_ack_backlog);
> }
> }
> + mptcp_data_unlock(sk);
>
> if (!info)
> return;
This seems overkill, and adds a new msk slock -> ilb->lock nesting from
mptcp_diag_dump_listeners(). It also makes ss randomly report msk
rmem/wmem instead of the accept queue while the listener is owned.
msk->first is a TCP socket: TCP listeners have SOCK_RCU_FREE, and
tcp_prot / tcpv6_prot use SLAB_TYPESAFE_BY_RCU. Reading two integers
under rcu_read_lock() is safe, and stale values are fine for diag.
mptcp_diag_dump_listeners() already holds rcu_read_lock(), only the
token dump and mptcp_diag_dump_one() paths are missing it.
Something like:
diff --git a/net/mptcp/mptcp_diag.c b/net/mptcp/mptcp_diag.c
index 136c2d05c0eeb8f7050344a63396396d8718206c..28a42eee665129fe56c47dc2dd5b265ba18b2e95
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)
pw-bot: cr
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH net] mptcp: protect listener backlog reads in diagnostics
2026-10-26 12:38 ` Eric Dumazet
@ 2026-10-26 14:44 ` Cen Zhang
0 siblings, 0 replies; 5+ messages in thread
From: Cen Zhang @ 2026-10-26 14:44 UTC (permalink / raw)
To: Eric Dumazet
Cc: matttbe, martineau, davem, kuba, pabeni, geliang, horms, netdev,
mptcp, linux-kernel, baijiaju1990, jjzuming
Hi Eric,
Eric Dumazet <edumazet@kernel.org> 于2026年10月26日周一 20:38写道：
>
> Adding these stack traces without symbols is not really nice.
>
> Time to use scripts/decode_stacktrace.sh
Sorry about that, v2 carries the report decoded with
scripts/decode_stacktrace.sh and trimmed to the relevant frames.
> msk->first is a TCP socket: TCP listeners have SOCK_RCU_FREE, and
> tcp_prot / tcpv6_prot use SLAB_TYPESAFE_BY_RCU. Reading two integers
> under rcu_read_lock() is safe, and stale values are fine for diag.
Thanks for the suggestions.
Best regards,
Cen Zhang
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH net] mptcp: protect listener backlog reads in diagnostics
2026-10-26 12:04 [PATCH net] mptcp: protect listener backlog reads in diagnostics Cen Zhang
2026-10-26 12:10 ` netdev-bot+sinfo
2026-10-26 12:38 ` Eric Dumazet
@ 2026-10-30 12:31 ` netdev-bot+sashiko
2 siblings, 0 replies; 5+ messages in thread
From: netdev-bot+sashiko @ 2026-10-30 12:31 UTC (permalink / raw)
To: zzzccc427
Cc: matttbe, martineau, davem, edumazet, kuba, pabeni, geliang,
horms, netdev, mptcp, linux-kernel, baijiaju1990, jjzuming
Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider.
Critical: 0 · High: 0 · Medium: 1 · Low: 0
If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).
- [Medium] In net/mptcp/mptcp_diag.c, mptcp_diag_get_info() now only
applies the listener override when the socket is not owned: `if…
--
mptcp: protect listener backlog reads in diagnostics
This commit takes the MPTCP data lock in mptcp_diag_get_info() around the
listener state check and the backlog reads. The override from msk->first
is now applied only when no process owns the socket. The goal is to fix a
use-after-free on the token based diag paths, which can race with a
disconnect, re-listen and close of the same socket.
> diff --git a/net/mptcp/mptcp_diag.c b/net/mptcp/mptcp_diag.c
> index 136c2d05c0eeb..a71bcaee15c8d 100644
> --- a/net/mptcp/mptcp_diag.c
> +++ b/net/mptcp/mptcp_diag.c
> @@ -199,7 +199,12 @@ static void mptcp_diag_get_info(struct sock *sk, struct inet_diag_msg *r,
> READ_ONCE(mptcp_sk(sk)->backlog_len);
> r->idiag_wqueue = sk_wmem_alloc_get(sk);
>
> - if (inet_sk_state_load(sk) == TCP_LISTEN) {
> + /* The listener walk holds the listen hash lock: do not wait for a
> + * socket owner that could be unhashing the first subflow.
> + */
> + mptcp_data_lock(sk);
> + if (!sock_owned_by_user(sk) &&
> + inet_sk_state_load(sk) == TCP_LISTEN) {
> struct sock *lsk = READ_ONCE(msk->first);
>
> if (lsk) {
[Severity: Medium]
mptcp_diag_get_info() is the shared idiag_get_info callback, so this new
sock_owned_by_user() check also applies to mptcp_diag_dump_listeners().
mptcp_listen() never inserts the msk into the token table. Isn't the
listener walk then the main way a listening MPTCP socket gets reported?
While a task holds lock_sock() on the listening msk, the override is
skipped. That covers listen(), most mptcp_setsockopt() and
mptcp_getsockopt() calls, shutdown and close, and the worker. In that
case only the fallback values are reported:
r->idiag_rqueue = sk_rmem_alloc_get(sk) +
READ_ONCE(mptcp_sk(sk)->backlog_len);
r->idiag_wqueue = sk_wmem_alloc_get(sk);
For a listener these are normally 0/0, not the accept queue length and
the max backlog. Could this make ss -Ml and accept queue monitoring show
occasional 0/0 readings for MPTCP listeners?
For comparison, tcp_diag_get_info() always reports sk_ack_backlog and
sk_max_ack_backlog for TCP_LISTEN, with no ownership check:
net/ipv4/tcp_diag.c:tcp_diag_get_info() {
if (inet_sk_state_load(sk) == TCP_LISTEN) {
r->idiag_rqueue = READ_ONCE(sk->sk_ack_backlog);
r->idiag_wqueue = READ_ONCE(sk->sk_max_ack_backlog);
...
}
The listener walk also looks like it was already memory safe before this
patch:
net/mptcp/mptcp_diag.c:mptcp_diag_dump_listeners() {
...
rcu_read_lock();
spin_lock(&ilb->lock);
sk_nulls_for_each(sk, node, &ilb->nulls_head) {
...
ret = sk_diag_dump(sk, skb, cb, r, net_admin);
...
}
Releasing the hashed listener subflow goes through
tcp_set_state(TCP_CLOSE)->inet_unhash(), which takes the same ilb->lock.
Hashed listeners are also SOCK_RCU_FREE.
The use-after-free described in the commit message seems reachable only
from the token based paths: the token iteration in mptcp_diag_dump() and
mptcp_diag_dump_one(). On those paths TCP_LISTEN shows up only in the
disconnect and re-listen race.
The commit message accepts the tradeoff:
While a process owns the socket, the dump reports the MPTCP socket's
own queue values instead.
It doesn't explain why the listener walk needs the check, though. Is the
ownership check needed on the mptcp_diag_dump_listeners() path, or could
it be limited to the token based callers?
With this change, the existing comment inside the if (lsk) block, "so
Send-Q will show accept queue", only holds while the socket is not owned.
[ ... ]
--
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/pm-mptcp-objects-candidate-0066-v3-73df72b7a543d4cada0e%40gmail.com
^ permalink raw reply [flat|nested] 5+ messages in thread