Re: [RFC net-next v10] mptcp: normalize seq numbers reported in mptcp_info

[Matthieu Baerts <matttbe@kernel.org>]

Hi Kalpan,

On 27/10/2026 07:27, Kalpan Jani wrote:
> Normalize the MPTCP sequence fields relative to the initial data sequence
> number baselines.
> 
> Keep the normalized values available to privileged diagnostic requests,
> while zeroing them in INET_DIAG_INFO for callers without CAP_NET_ADMIN.
> 
> Normalize MPTCP_SUBFLOW_ATTR_MAP_SEQ against remote_idsn as well, so
> subflow mapping sequence numbers use the same remote sequence space as
> mptcpi_rcv_nxt.
> 
> Pass requester capability state to idiag_get_info callbacks. Other
> protocol callbacks retain their existing behavior.
> 
> Link: https://github.com/multipath-tcp/mptcp_net-next/issues/445
> Signed-off-by: Kalpan Jani <kalpan.jani@mpiricsoftware.com>
> ---
> Changes since v9:

Thank you for the new version!

> - Keep normalized sequence values available to privileged diagnostic
>   requests and zero the three sequence fields for unprivileged
>   INET_DIAG_INFO callers.
> - Pass requester capability state to idiag_get_info callbacks while
>   preserving existing behavior for other protocol callbacks.

I think it should be one or the other: the suggestion to disable the
different fields for non net-admin is a sort of workaround not to have
to deal with the possible issues reported by Sashiko.

If we take this route, the only modifications on MPTCP side would be in
the diag files (or if you have fixes, they can be in separated patches).
Also, it would be easier to split this change in two: exposing the
net_admin boolean, then modifying MPTCP to hide data.

BTW, using the bytes sent/received was not something that could be used
here?

> - Normalize MPTCP_SUBFLOW_ATTR_MAP_SEQ relative to remote_idsn so it
>   uses the same remote sequence-number baseline as mptcpi_rcv_nxt.

I guess it would be 0 for non net-admin.

(...)

> diff --git a/net/ipv4/inet_diag.c b/net/ipv4/inet_diag.c
> index 34b77aa87d0a4..362161bf39fe3 100644
> --- a/net/ipv4/inet_diag.c
> +++ b/net/ipv4/inet_diag.c
> @@ -276,7 +276,7 @@ int inet_sk_diag_fill(struct sock *sk, struct inet_connection_sock *icsk,
>  	}
>  
>  	if (!icsk) {
> -		handler->idiag_get_info(sk, r, NULL);
> +		handler->idiag_get_info(sk, r, NULL, net_admin);
>  		goto out;
>  	}
>  
> @@ -327,7 +327,7 @@ int inet_sk_diag_fill(struct sock *sk, struct inet_connection_sock *icsk,
>  			goto errout;
>  	}
>  
> -	handler->idiag_get_info(sk, r, info);
> +	handler->idiag_get_info(sk, r, info, net_admin);
>  
>  	if (ext & (1 << (INET_DIAG_INFO - 1)) && handler->idiag_get_aux)
>  		if (handler->idiag_get_aux(sk, net_admin, skb) < 0)
> @@ -1027,7 +1027,7 @@ int inet_diag_handler_get_info(struct sk_buff *skb, struct sock *sk)
>  	if (attr)
>  		info = nla_data(attr);
>  
> -	handler->idiag_get_info(sk, r, info);
> +	handler->idiag_get_info(sk, r, info, false);

I didn't check, but can you not extract the capability from the skb?

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.