diff mbox series

[mptcp-net,v2] tcp: check mptcp-level constraints for backlog coalescing

Message ID f1e771e52c4dce3db4884ac0e629d363d1676b75.1697037788.git.pabeni@redhat.com (mailing list archive)
State Accepted, archived
Commit 1d6459245311d14cf57960cdfb808ebcf49213eb
Delegated to: Matthieu Baerts
Headers show
Series [mptcp-net,v2] tcp: check mptcp-level constraints for backlog coalescing | expand

Checks

Context Check Description
matttbe/build success Build and static analysis OK
matttbe/checkpatch success total: 0 errors, 0 warnings, 0 checks, 7 lines checked
matttbe/KVM_Validation__normal__except_selftest_mptcp_join_ success Success! ✅
matttbe/KVM_Validation__debug__except_selftest_mptcp_join_ success Success! ✅
matttbe/KVM_Validation__normal__only_selftest_mptcp_join_ success Success! ✅
matttbe/KVM_Validation__debug__only_selftest_mptcp_join_ warning Unstable: 1 failed test(s): selftest_mptcp_join

Commit Message

Paolo Abeni Oct. 11, 2023, 3:23 p.m. UTC
The MPTCP protocol can acquire the subflow-level socket lock and
cause the tcp backlog usage. When inserting new skbs into the
backlog, the stack will try to coalesce them.

Currently, we have no check in place to ensure that such coalescing
will respect the MPTCP-level DSS, and that may cause data stream
corruption, as reported by Christoph.

Address the issue by adding the relevant admission check for coalescing
in tcp_add_backlog().

Note the issue is not easy to reproduce, as the MPTCP protocol tries
hard to avoid acquiring the subflow-level socket lock.

Fixes: 648ef4b88673 ("mptcp: Implement MPTCP receive path")
Reported-by: Christoph Paasch <cpaasch@apple.com>
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/420
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
v1 -> v2:
  - !coalesce (mat)
  - typo in commit message (mat)
---
 net/ipv4/tcp_ipv4.c | 1 +
 1 file changed, 1 insertion(+)

Comments

MPTCP CI Oct. 11, 2023, 4:31 p.m. UTC | #1
Hi Paolo,

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! ✅:
  - Task: https://cirrus-ci.com/task/5873231270248448
  - Summary: https://api.cirrus-ci.com/v1/artifact/task/5873231270248448/summary/summary.txt

- KVM Validation: debug (except selftest_mptcp_join):
  - Success! ✅:
  - Task: https://cirrus-ci.com/task/6659777703444480
  - Summary: https://api.cirrus-ci.com/v1/artifact/task/6659777703444480/summary/summary.txt

- KVM Validation: normal (only selftest_mptcp_join):
  - Success! ✅:
  - Task: https://cirrus-ci.com/task/5533877796601856
  - Summary: https://api.cirrus-ci.com/v1/artifact/task/5533877796601856/summary/summary.txt

- KVM Validation: debug (only selftest_mptcp_join):
  - Unstable: 1 failed test(s): selftest_mptcp_join 
Mat Martineau Oct. 11, 2023, 5:25 p.m. UTC | #2
On Wed, 11 Oct 2023, Paolo Abeni wrote:

> The MPTCP protocol can acquire the subflow-level socket lock and
> cause the tcp backlog usage. When inserting new skbs into the
> backlog, the stack will try to coalesce them.
>
> Currently, we have no check in place to ensure that such coalescing
> will respect the MPTCP-level DSS, and that may cause data stream
> corruption, as reported by Christoph.
>
> Address the issue by adding the relevant admission check for coalescing
> in tcp_add_backlog().
>
> Note the issue is not easy to reproduce, as the MPTCP protocol tries
> hard to avoid acquiring the subflow-level socket lock.
>
> Fixes: 648ef4b88673 ("mptcp: Implement MPTCP receive path")
> Reported-by: Christoph Paasch <cpaasch@apple.com>
> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/420
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---
> v1 -> v2:
>  - !coalesce (mat)
>  - typo in commit message (mat)

Thanks Paolo, v2 LGTM:

Reviewed-by: Mat Martineau <martineau@kernel.org>

> ---
> net/ipv4/tcp_ipv4.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> index a441740616d7..4d66a8ab3b98 100644
> --- a/net/ipv4/tcp_ipv4.c
> +++ b/net/ipv4/tcp_ipv4.c
> @@ -1870,6 +1870,7 @@ bool tcp_add_backlog(struct sock *sk, struct sk_buff *skb,
> #ifdef CONFIG_TLS_DEVICE
> 	    tail->decrypted != skb->decrypted ||
> #endif
> +	    !mptcp_skb_can_collapse(tail, skb) ||
> 	    thtail->doff != th->doff ||
> 	    memcmp(thtail + 1, th + 1, hdrlen - sizeof(*th)))
> 		goto no_coalesce;
> -- 
> 2.41.0
>
>
>
Matthieu Baerts (NGI0) Oct. 12, 2023, 8:38 a.m. UTC | #3
Hi Paolo, Mat,

On 11/10/2023 17:23, Paolo Abeni wrote:
> The MPTCP protocol can acquire the subflow-level socket lock and
> cause the tcp backlog usage. When inserting new skbs into the
> backlog, the stack will try to coalesce them.
> 
> Currently, we have no check in place to ensure that such coalescing
> will respect the MPTCP-level DSS, and that may cause data stream
> corruption, as reported by Christoph.
> 
> Address the issue by adding the relevant admission check for coalescing
> in tcp_add_backlog().
> 
> Note the issue is not easy to reproduce, as the MPTCP protocol tries
> hard to avoid acquiring the subflow-level socket lock.

Thank you for the patch and the review!

Now in our tree (fixes for -net):

New patches for t/upstream-net and t/upstream:
- 1d6459245311: tcp: check mptcp-level constraints for backlog coalescing
- Results: 08ccf8391935..b490362cfb13 (export-net)
- Results: a3a484f2dee3..54aab2945697 (export)

Tests are now in progress:

https://cirrus-ci.com/github/multipath-tcp/mptcp_net-next/export-net/20231012T083551
https://cirrus-ci.com/github/multipath-tcp/mptcp_net-next/export/20231012T083551

Cheers,
Matt
diff mbox series

Patch

diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index a441740616d7..4d66a8ab3b98 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1870,6 +1870,7 @@  bool tcp_add_backlog(struct sock *sk, struct sk_buff *skb,
 #ifdef CONFIG_TLS_DEVICE
 	    tail->decrypted != skb->decrypted ||
 #endif
+	    !mptcp_skb_can_collapse(tail, skb) ||
 	    thtail->doff != th->doff ||
 	    memcmp(thtail + 1, th + 1, hdrlen - sizeof(*th)))
 		goto no_coalesce;