[PATCH net] mptcp: return sk_wait_data() errors from recvmsg()

[PATCH net] mptcp: return sk_wait_data() errors from recvmsg()

[Mark Amirkan via B4 Relay]

From: Mark Amirkan <markdamirkan@gmail.com>

Commit 581302298524 ("mptcp: error out earlier on disconnect") made
mptcp_recvmsg() stop when sk_wait_data() returns an error.  The error is
stored in err, but the function then jumps to a path which returns
copied.  When no data was copied, recvmsg() therefore returns zero and
reports a false EOF.

Store the result in copied, which is the value returned by the function.
This also keeps the usual partial-read result when data was copied before
the error.

A recvmsg() blocked in one thread reproduces the issue when another
thread disconnects the same MPTCP socket with connect(AF_UNSPEC).
Before this change recvmsg() returns zero; afterwards it returns -EPIPE.

Fixes: 581302298524 ("mptcp: error out earlier on disconnect")
Cc: stable@vger.kernel.org
Assisted-by: Symbolic
Signed-off-by: Mark Amirkan <markdamirkan@gmail.com>
---
 net/mptcp/protocol.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 0098e28309..8dc25ef154 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -2459,7 +2459,7 @@ static int mptcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
 		mptcp_cleanup_rbuf(msk, copied);
 		err = sk_wait_data(sk, &timeo, last);
 		if (err < 0) {
-			err = copied ? : err;
+			copied = copied ? : err;
 			goto out_err;
 		}
 	}

---
base-commit: 78445023439506ebd83b86d40b1e428a3b309d4a
change-id: 20260913-b4-send-mptcp-recv-error-ef0f898e05cc

Best regards,
--  
Mark Amirkan <markdamirkan@gmail.com>

[PATCH net] mptcp: return sk_wait_data() errors from recvmsg()

[Mark Amirkan]

Commit 581302298524 ("mptcp: error out earlier on disconnect") made
mptcp_recvmsg() stop when sk_wait_data() returns an error.  The error is
stored in err, but the function then jumps to a path which returns
copied.  When no data was copied, recvmsg() therefore returns zero and
reports a false EOF.

Store the result in copied, which is the value returned by the function.
This also keeps the usual partial-read result when data was copied before
the error.

A recvmsg() blocked in one thread reproduces the issue when another
thread disconnects the same MPTCP socket with connect(AF_UNSPEC).
Before this change recvmsg() returns zero; afterwards it returns -EPIPE.

Fixes: 581302298524 ("mptcp: error out earlier on disconnect")
Cc: stable@vger.kernel.org
Assisted-by: Symbolic
Signed-off-by: Mark Amirkan <markdamirkan@gmail.com>
---
 net/mptcp/protocol.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 0098e28309..8dc25ef154 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -2459,7 +2459,7 @@ static int mptcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
 		mptcp_cleanup_rbuf(msk, copied);
 		err = sk_wait_data(sk, &timeo, last);
 		if (err < 0) {
-			err = copied ? : err;
+			copied = copied ? : err;
 			goto out_err;
 		}
 	}

---
base-commit: 78445023439506ebd83b86d40b1e428a3b309d4a
change-id: 20260913-b4-send-mptcp-recv-error-ef0f898e05cc

Best regards,
--  
Mark Amirkan <markdamirkan@gmail.com>

Re: [PATCH net] mptcp: return sk_wait_data() errors from recvmsg()

[MPTCP CI]

Hi Mark,

Thank you for your modifications, that's great!

Our CI did some validations and here is its report:

- KVM Validation: normal (except selftest_mptcp_join): Success! ✅
- KVM Validation: normal (only selftest_mptcp_join): Success! ✅
- KVM Validation: debug (except selftest_mptcp_join): Success! ✅
- KVM Validation: debug (only selftest_mptcp_join): Success! ✅
- KVM Validation: btf-normal (only bpftest_all): Success! ✅
- KVM Validation: btf-debug (only bpftest_all): Success! ✅
- Perf: Success! ✅
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/34752330865

Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/0f0aa4cd4256
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=1163763


If there are some issues, you can reproduce them using the same environment as
the one used by the CI thanks to a docker image, e.g.:

    $ cd [kernel source code]
    $ docker run -v "${PWD}:${PWD}:rw" -w "${PWD}" --privileged --rm -it \
        --pull always mptcp/mptcp-upstream-virtme-docker:latest \
        auto-normal

For more details:

    https://github.com/multipath-tcp/mptcp-upstream-virtme-docker


Please note that despite all the efforts that have been already done to have a
stable tests suite when executed on a public CI like here, it is possible some
reported issues are not due to your modifications. Still, do not hesitate to
help us improve that ;-)

Cheers,
MPTCP GH Action bot
Bot operated by Matthieu Baerts (NGI0 Core)

Re: [PATCH net] mptcp: return sk_wait_data() errors from recvmsg()

[Matthieu Baerts]

Hi Mark,

On 13/09/2026 12:30, Mark Amirkan via B4 Relay wrote:
> From: Mark Amirkan <markdamirkan@gmail.com>
> 
> Commit 581302298524 ("mptcp: error out earlier on disconnect") made
> mptcp_recvmsg() stop when sk_wait_data() returns an error.  The error is
> stored in err, but the function then jumps to a path which returns
> copied.  When no data was copied, recvmsg() therefore returns zero and
> reports a false EOF.
> 
> Store the result in copied, which is the value returned by the function.
> This also keeps the usual partial-read result when data was copied before
> the error.

Good catch! Indeed, it looks like it is a typo and "copied" was supposed
to be assigned.

Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>

@Net maintainers: can you please apply it directly in the net tree? (if
no issues are spot by Clashiko) No need to take a detour via the MPTCP
tree for this fix.

> A recvmsg() blocked in one thread reproduces the issue when another
> thread disconnects the same MPTCP socket with connect(AF_UNSPEC).
> Before this change recvmsg() returns zero; afterwards it returns -EPIPE.

I see that our test suite currently doesn't exercise this error path. By
chance, do you have a reproducer to avoid similar regressions later on?
Ideally, one using Packetdrill, the MPTCP fork in this case [1].

[1] https://github.com/multipath-tcp/packetdrill

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