Re: [PATCH net] mptcp: protect listener backlog reads in diagnostics

[netdev-bot+sashiko@kernel.org]

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