MPTCP Linux Development
 help / color / mirror / Atom feed
From: Mat Martineau <martineau@kernel.org>
To: Paolo Abeni <pabeni@redhat.com>
Cc: mptcp@lists.linux.dev, Geliang Tang <geliang@kernel.org>
Subject: Re: [PATCH v6 mptcp-next 05/11] mptcp: fix MSG_PEEK stream corruption
Date: Thu, 23 Oct 2025 09:56:07 -0700 (PDT)	[thread overview]
Message-ID: <9a415164-74cb-3650-9299-edc82652b086@kernel.org> (raw)
In-Reply-To: <d110f41af91c7b3feb17b6b5942c21cdcec93c13.1761142784.git.pabeni@redhat.com>

On Wed, 22 Oct 2025, Paolo Abeni wrote:

> If a MSG_PEEK | MSG_WAITALL read operation consumes all the bytes in the
> receive queue and recvmsg() need to waits for more data - i.e. it's a
> blocking one - upon arrival of the next packet the MPTCP protocol will
> start again copying the oldest data present in the receive queue,
> corrupting the data stream.
>
> Address the issue explicitly tracking the peeked sequence number,
> restarting from the last peeked byte.
>
> Fixes: ca4fb892579f ("mptcp: add MSG_PEEK support")
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---
> This may sound quite esoteric, but it will soon become very easy to
> reproduce with mptcp_connect, thanks to the backlog.

Would it be good to apply this to -net?

- Mat

> ---
> net/mptcp/protocol.c | 38 +++++++++++++++++++++++++-------------
> 1 file changed, 25 insertions(+), 13 deletions(-)
>
> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
> index 51c55a45aeaccd..200b657080eb3e 100644
> --- a/net/mptcp/protocol.c
> +++ b/net/mptcp/protocol.c
> @@ -1947,22 +1947,36 @@ static int mptcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
>
> static void mptcp_rcv_space_adjust(struct mptcp_sock *msk, int copied);
>
> -static int __mptcp_recvmsg_mskq(struct sock *sk,
> -				struct msghdr *msg,
> -				size_t len, int flags,
> +static int __mptcp_recvmsg_mskq(struct sock *sk, struct msghdr *msg,
> +				size_t len, int flags, int copied_total,
> 				struct scm_timestamping_internal *tss,
> 				int *cmsg_flags)
> {
> 	struct mptcp_sock *msk = mptcp_sk(sk);
> 	struct sk_buff *skb, *tmp;
> +	int total_data_len = 0;
> 	int copied = 0;
>
> 	skb_queue_walk_safe(&sk->sk_receive_queue, skb, tmp) {
> -		u32 offset = MPTCP_SKB_CB(skb)->offset;
> +		u32 delta, offset = MPTCP_SKB_CB(skb)->offset;
> 		u32 data_len = skb->len - offset;
> -		u32 count = min_t(size_t, len - copied, data_len);
> +		u32 count;
> 		int err;
>
> +		if (flags & MSG_PEEK) {
> +			/* skip already peeked skbs*/
> +			if (total_data_len + data_len <= copied_total) {
> +				total_data_len += data_len;
> +				continue;
> +			}
> +
> +			/* skip the already peeked data in the current skb */
> +			delta = copied_total - total_data_len;
> +			offset += delta;
> +			data_len -= delta;
> +		}
> +
> +		count = min_t(size_t, len - copied, data_len);
> 		if (!(flags & MSG_TRUNC)) {
> 			err = skb_copy_datagram_msg(skb, offset, msg, count);
> 			if (unlikely(err < 0)) {
> @@ -1979,16 +1993,14 @@ static int __mptcp_recvmsg_mskq(struct sock *sk,
>
> 		copied += count;
>
> -		if (count < data_len) {
> -			if (!(flags & MSG_PEEK)) {
> +		if (!(flags & MSG_PEEK)) {
> +			msk->bytes_consumed += count;
> +			if (count < data_len) {
> 				MPTCP_SKB_CB(skb)->offset += count;
> 				MPTCP_SKB_CB(skb)->map_seq += count;
> -				msk->bytes_consumed += count;
> +				break;
> 			}
> -			break;
> -		}
>
> -		if (!(flags & MSG_PEEK)) {
> 			/* avoid the indirect call, we know the destructor is sock_rfree */
> 			skb->destructor = NULL;
> 			skb->sk = NULL;
> @@ -1996,7 +2008,6 @@ static int __mptcp_recvmsg_mskq(struct sock *sk,
> 			sk_mem_uncharge(sk, skb->truesize);
> 			__skb_unlink(skb, &sk->sk_receive_queue);
> 			skb_attempt_defer_free(skb);
> -			msk->bytes_consumed += count;
> 		}
>
> 		if (copied >= len)
> @@ -2194,7 +2205,8 @@ static int mptcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
> 	while (copied < len) {
> 		int err, bytes_read;
>
> -		bytes_read = __mptcp_recvmsg_mskq(sk, msg, len - copied, flags, &tss, &cmsg_flags);
> +		bytes_read = __mptcp_recvmsg_mskq(sk, msg, len - copied, flags,
> +						  copied, &tss, &cmsg_flags);
> 		if (unlikely(bytes_read < 0)) {
> 			if (!copied)
> 				copied = bytes_read;
> -- 
> 2.51.0
>
>
>

  reply	other threads:[~2025-10-23 16:56 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-22 14:31 [PATCH v6 mptcp-next 00/11] mptcp: introduce backlog processing Paolo Abeni
2025-10-22 14:31 ` [PATCH v6 mptcp-next 01/11] mptcp: drop bogus optimization in __mptcp_check_push() Paolo Abeni
2025-10-22 14:31 ` [PATCH v6 mptcp-next 02/11] mptcp: borrow forward memory from subflow Paolo Abeni
2025-10-23  6:38   ` Geliang Tang
2025-10-22 14:31 ` [PATCH v6 mptcp-next 03/11] mptcp: cleanup fallback data fin reception Paolo Abeni
2025-10-22 14:31 ` [PATCH v6 mptcp-next 04/11] mptcp: cleanup fallback dummy mapping generation Paolo Abeni
2025-10-22 14:31 ` [PATCH v6 mptcp-next 05/11] mptcp: fix MSG_PEEK stream corruption Paolo Abeni
2025-10-23 16:56   ` Mat Martineau [this message]
2025-10-24  7:34     ` Paolo Abeni
2025-10-22 14:31 ` [PATCH v6 mptcp-next 06/11] mptcp: ensure the kernel PM does not take action too late Paolo Abeni
2025-10-22 14:31 ` [PATCH v6 mptcp-next 07/11] mptcp: do not miss early first subflow close event notification Paolo Abeni
2025-10-22 14:31 ` [PATCH v6 mptcp-next 08/11] mptcp: make mptcp_destroy_common() static Paolo Abeni
2025-10-22 14:31 ` [PATCH v6 mptcp-next 09/11] mptcp: drop the __mptcp_data_ready() helper Paolo Abeni
2025-10-23  6:38   ` Geliang Tang
2025-10-22 14:31 ` [PATCH v6 mptcp-next 10/11] mptcp: introduce mptcp-level backlog Paolo Abeni
2025-10-22 14:31 ` [PATCH v6 mptcp-next 11/11] mptcp: leverage the backlog for RX packet processing Paolo Abeni
2025-10-23 15:11   ` Paolo Abeni
2025-10-23 15:52     ` Matthieu Baerts
2025-10-23 17:02       ` Mat Martineau
2025-10-23 17:43         ` Matthieu Baerts
2025-10-22 15:50 ` [PATCH v6 mptcp-next 00/11] mptcp: introduce backlog processing MPTCP CI
2025-10-23  6:37 ` Geliang Tang
2025-10-27 12:17 ` Matthieu Baerts

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=9a415164-74cb-3650-9299-edc82652b086@kernel.org \
    --to=martineau@kernel.org \
    --cc=geliang@kernel.org \
    --cc=mptcp@lists.linux.dev \
    --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