[PATCH net 0/3] mptcp: fix data stream corruption and missing sockopts

[PATCH net 0/3] mptcp: fix data stream corruption and missing sockopts

[Matthieu Baerts (NGI0)]

Here are 3 unrelated fixes for the net tree.

- Patch 1: fix data stream corruption when ending up not sending an
  ADD_ADDR.

- Patch 2: fix missing getsockopt(IPV6_V6ONLY) support -- the set part
  is supported.

- Patch 3: fix missing v4/v6 freebind & transparent getsockopt() -- the
  set part is supported.

Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
Notes:
 - Patch 1 has already been sent to netdev, but it has been applied in
   MPTCP tree first, including some small changes in the commit message.

---
Arthur Mongodin (1):
      mptcp: Fix data stream corruption in the address announcement

Matthieu Baerts (NGI0) (2):
      mptcp: sockopt: fix getting IPV6_V6ONLY
      mptcp: sockopt: fix getting freebind & transparent

 net/mptcp/options.c |  6 ++++--
 net/mptcp/sockopt.c | 28 ++++++++++++++++++++++++++++
 2 files changed, 32 insertions(+), 2 deletions(-)
---
base-commit: 4003c9e78778e93188a09d6043a74f7154449d43
change-id: 20250314-net-mptcp-fix-data-stream-corr-sockopt-98e1d4250951

Best regards,
-- 
Matthieu Baerts (NGI0) <matttbe@kernel.org>

[PATCH net 1/3] mptcp: Fix data stream corruption in the address announcement

[Matthieu Baerts (NGI0)]

From: Arthur Mongodin <amongodin@randorisec.fr>

Because of the size restriction in the TCP options space, the MPTCP
ADD_ADDR option is exclusive and cannot be sent with other MPTCP ones.
For this reason, in the linked mptcp_out_options structure, group of
fields linked to different options are part of the same union.

There is a case where the mptcp_pm_add_addr_signal() function can modify
opts->addr, but not ended up sending an ADD_ADDR. Later on, back in
mptcp_established_options, other options will be sent, but with
unexpected data written in other fields due to the union, e.g. in
opts->ext_copy. This could lead to a data stream corruption in the next
packet.

Using an intermediate variable, prevents from corrupting previously
established DSS option. The assignment of the ADD_ADDR option
parameters is now done once we are sure this ADD_ADDR option can be set
in the packet, e.g. after having dropped other suboptions.

Fixes: 1bff1e43a30e ("mptcp: optimize out option generation")
Cc: stable@vger.kernel.org
Suggested-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Arthur Mongodin <amongodin@randorisec.fr>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
[ Matt: the commit message has been updated: long lines splits and some
  clarifications. ]
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
 net/mptcp/options.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/net/mptcp/options.c b/net/mptcp/options.c
index fd2de185bc939f8730e87a63ac02a015e610e99c..23949ae2a3a8db19d05c5c8373f45c885c3523ad 100644
--- a/net/mptcp/options.c
+++ b/net/mptcp/options.c
@@ -651,6 +651,7 @@ static bool mptcp_established_options_add_addr(struct sock *sk, struct sk_buff *
 	struct mptcp_sock *msk = mptcp_sk(subflow->conn);
 	bool drop_other_suboptions = false;
 	unsigned int opt_size = *size;
+	struct mptcp_addr_info addr;
 	bool echo;
 	int len;
 
@@ -659,7 +660,7 @@ static bool mptcp_established_options_add_addr(struct sock *sk, struct sk_buff *
 	 */
 	if (!mptcp_pm_should_add_signal(msk) ||
 	    (opts->suboptions & (OPTION_MPTCP_MPJ_ACK | OPTION_MPTCP_MPC_ACK)) ||
-	    !mptcp_pm_add_addr_signal(msk, skb, opt_size, remaining, &opts->addr,
+	    !mptcp_pm_add_addr_signal(msk, skb, opt_size, remaining, &addr,
 		    &echo, &drop_other_suboptions))
 		return false;
 
@@ -672,7 +673,7 @@ static bool mptcp_established_options_add_addr(struct sock *sk, struct sk_buff *
 	else if (opts->suboptions & OPTION_MPTCP_DSS)
 		return false;
 
-	len = mptcp_add_addr_len(opts->addr.family, echo, !!opts->addr.port);
+	len = mptcp_add_addr_len(addr.family, echo, !!addr.port);
 	if (remaining < len)
 		return false;
 
@@ -689,6 +690,7 @@ static bool mptcp_established_options_add_addr(struct sock *sk, struct sk_buff *
 		opts->ahmac = 0;
 		*size -= opt_size;
 	}
+	opts->addr = addr;
 	opts->suboptions |= OPTION_MPTCP_ADD_ADDR;
 	if (!echo) {
 		MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_ADDADDRTX);

-- 
2.48.1

Re: [PATCH net 1/3] mptcp: Fix data stream corruption in the address announcement

[Simon Horman]

On Fri, Mar 14, 2025 at 09:11:31PM +0100, Matthieu Baerts (NGI0) wrote:
> From: Arthur Mongodin <amongodin@randorisec.fr>
> 
> Because of the size restriction in the TCP options space, the MPTCP
> ADD_ADDR option is exclusive and cannot be sent with other MPTCP ones.
> For this reason, in the linked mptcp_out_options structure, group of
> fields linked to different options are part of the same union.
> 
> There is a case where the mptcp_pm_add_addr_signal() function can modify
> opts->addr, but not ended up sending an ADD_ADDR. Later on, back in
> mptcp_established_options, other options will be sent, but with
> unexpected data written in other fields due to the union, e.g. in
> opts->ext_copy. This could lead to a data stream corruption in the next
> packet.
> 
> Using an intermediate variable, prevents from corrupting previously
> established DSS option. The assignment of the ADD_ADDR option
> parameters is now done once we are sure this ADD_ADDR option can be set
> in the packet, e.g. after having dropped other suboptions.
> 
> Fixes: 1bff1e43a30e ("mptcp: optimize out option generation")
> Cc: stable@vger.kernel.org
> Suggested-by: Paolo Abeni <pabeni@redhat.com>
> Signed-off-by: Arthur Mongodin <amongodin@randorisec.fr>
> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
> [ Matt: the commit message has been updated: long lines splits and some
>   clarifications. ]
> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>

Reviewed-by: Simon Horman <horms@kernel.org>

Re: [PATCH net 1/3] mptcp: Fix data stream corruption in the address announcement

[Simon Horman]

On Fri, Mar 14, 2025 at 09:11:31PM +0100, Matthieu Baerts (NGI0) wrote:
> From: Arthur Mongodin <amongodin@randorisec.fr>
> 
> Because of the size restriction in the TCP options space, the MPTCP
> ADD_ADDR option is exclusive and cannot be sent with other MPTCP ones.
> For this reason, in the linked mptcp_out_options structure, group of
> fields linked to different options are part of the same union.
> 
> There is a case where the mptcp_pm_add_addr_signal() function can modify
> opts->addr, but not ended up sending an ADD_ADDR. Later on, back in
> mptcp_established_options, other options will be sent, but with
> unexpected data written in other fields due to the union, e.g. in
> opts->ext_copy. This could lead to a data stream corruption in the next
> packet.
> 
> Using an intermediate variable, prevents from corrupting previously
> established DSS option. The assignment of the ADD_ADDR option
> parameters is now done once we are sure this ADD_ADDR option can be set
> in the packet, e.g. after having dropped other suboptions.
> 
> Fixes: 1bff1e43a30e ("mptcp: optimize out option generation")
> Cc: stable@vger.kernel.org
> Suggested-by: Paolo Abeni <pabeni@redhat.com>
> Signed-off-by: Arthur Mongodin <amongodin@randorisec.fr>
> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
> [ Matt: the commit message has been updated: long lines splits and some
>   clarifications. ]
> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>

Reviewed-by: Simon Horman <horms@kernel.org>

[PATCH net 2/3] mptcp: sockopt: fix getting IPV6_V6ONLY

[Matthieu Baerts (NGI0)]

When adding a socket option support in MPTCP, both the get and set parts
are supposed to be implemented.

IPV6_V6ONLY support for the setsockopt part has been added a while ago,
but it looks like the get part got forgotten. It should have been
present as a way to verify a setting has been set as expected, and not
to act differently from TCP or any other socket types.

Not supporting this getsockopt(IPV6_V6ONLY) blocks some apps which want
to check the default value, before doing extra actions. On Linux, the
default value is 0, but this can be changed with the net.ipv6.bindv6only
sysctl knob. On Windows, it is set to 1 by default. So supporting the
get part, like for all other socket options, is important.

Everything was in place to expose it, just the last step was missing.
Only new code is added to cover this specific getsockopt(), that seems
safe.

Fixes: c9b95a135987 ("mptcp: support IPV6_V6ONLY setsockopt")
Cc: stable@vger.kernel.org
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/550
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
 net/mptcp/sockopt.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/net/mptcp/sockopt.c b/net/mptcp/sockopt.c
index 505445a9598fafa1cde6d8f4a1a8635c3e778051..4b99eb796855e4578d14df90f9d1cc3f1cd5b8c7 100644
--- a/net/mptcp/sockopt.c
+++ b/net/mptcp/sockopt.c
@@ -1430,6 +1430,20 @@ static int mptcp_getsockopt_v4(struct mptcp_sock *msk, int optname,
 	return -EOPNOTSUPP;
 }
 
+static int mptcp_getsockopt_v6(struct mptcp_sock *msk, int optname,
+			       char __user *optval, int __user *optlen)
+{
+	struct sock *sk = (void *)msk;
+
+	switch (optname) {
+	case IPV6_V6ONLY:
+		return mptcp_put_int_option(msk, optval, optlen,
+					    sk->sk_ipv6only);
+	}
+
+	return -EOPNOTSUPP;
+}
+
 static int mptcp_getsockopt_sol_mptcp(struct mptcp_sock *msk, int optname,
 				      char __user *optval, int __user *optlen)
 {
@@ -1469,6 +1483,8 @@ int mptcp_getsockopt(struct sock *sk, int level, int optname,
 
 	if (level == SOL_IP)
 		return mptcp_getsockopt_v4(msk, optname, optval, option);
+	if (level == SOL_IPV6)
+		return mptcp_getsockopt_v6(msk, optname, optval, option);
 	if (level == SOL_TCP)
 		return mptcp_getsockopt_sol_tcp(msk, optname, optval, option);
 	if (level == SOL_MPTCP)

-- 
2.48.1

Re: [PATCH net 2/3] mptcp: sockopt: fix getting IPV6_V6ONLY

[Simon Horman]

On Fri, Mar 14, 2025 at 09:11:32PM +0100, Matthieu Baerts (NGI0) wrote:
> When adding a socket option support in MPTCP, both the get and set parts
> are supposed to be implemented.
> 
> IPV6_V6ONLY support for the setsockopt part has been added a while ago,
> but it looks like the get part got forgotten. It should have been
> present as a way to verify a setting has been set as expected, and not
> to act differently from TCP or any other socket types.
> 
> Not supporting this getsockopt(IPV6_V6ONLY) blocks some apps which want
> to check the default value, before doing extra actions. On Linux, the
> default value is 0, but this can be changed with the net.ipv6.bindv6only
> sysctl knob. On Windows, it is set to 1 by default. So supporting the
> get part, like for all other socket options, is important.
> 
> Everything was in place to expose it, just the last step was missing.
> Only new code is added to cover this specific getsockopt(), that seems
> safe.
> 
> Fixes: c9b95a135987 ("mptcp: support IPV6_V6ONLY setsockopt")
> Cc: stable@vger.kernel.org
> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/550
> Reviewed-by: Mat Martineau <martineau@kernel.org>
> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>

Hi Matthieu, all,

TBH, I would lean towards this being net-next material rather than a fix
for net. But that notwithstanding this looks good to me.

Reviewed-by: Simon Horman <horms@kernel.org>

Re: [PATCH net 2/3] mptcp: sockopt: fix getting IPV6_V6ONLY

[Matthieu Baerts]

Hi Simon,

Thank you for your review!

On 19/03/2025 16:38, Simon Horman wrote:
> On Fri, Mar 14, 2025 at 09:11:32PM +0100, Matthieu Baerts (NGI0) wrote:
>> When adding a socket option support in MPTCP, both the get and set parts
>> are supposed to be implemented.
>>
>> IPV6_V6ONLY support for the setsockopt part has been added a while ago,
>> but it looks like the get part got forgotten. It should have been
>> present as a way to verify a setting has been set as expected, and not
>> to act differently from TCP or any other socket types.
>>
>> Not supporting this getsockopt(IPV6_V6ONLY) blocks some apps which want
>> to check the default value, before doing extra actions. On Linux, the
>> default value is 0, but this can be changed with the net.ipv6.bindv6only
>> sysctl knob. On Windows, it is set to 1 by default. So supporting the
>> get part, like for all other socket options, is important.
>>
>> Everything was in place to expose it, just the last step was missing.
>> Only new code is added to cover this specific getsockopt(), that seems
>> safe.
>>
>> Fixes: c9b95a135987 ("mptcp: support IPV6_V6ONLY setsockopt")
>> Cc: stable@vger.kernel.org
>> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/550
>> Reviewed-by: Mat Martineau <martineau@kernel.org>
>> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
> 
> Hi Matthieu, all,
> 
> TBH, I would lean towards this being net-next material rather than a fix
> for net. But that notwithstanding this looks good to me.
I understand. This patch and the next one target "net" because, with
MPTCP, we try to mimic TCP when interacting with the userspace.

Not supporting "getsockopt(IPV6_V6ONLY)" breaks some legacy apps forced
to use MPTCP instead of TCP. These apps apparently "strangely" check
this "getsockopt(IPV6_V6ONLY)" before changing the behaviour with
"setsockopt(IPV6_V6ONLY)" which is supported for a long time. The "get"
part should have been added from the beginning, and I don't see this
patch as a new feature. Because it simply sets an integer like most
other "get" options, it seems better to target net and fix these apps
ASAP rather than targeting net-next and delay this "safe" fix.

If that's OK, I would then prefer if these patches are applied in "net".
Or they can be applied in "net-next" if we can keep their "Cc: stable"
and "Fixes" tags, but that looks strange.

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

Re: [PATCH net 2/3] mptcp: sockopt: fix getting IPV6_V6ONLY

[Paolo Abeni]

On 3/19/25 5:26 PM, Matthieu Baerts wrote:
> On 19/03/2025 16:38, Simon Horman wrote:
>> On Fri, Mar 14, 2025 at 09:11:32PM +0100, Matthieu Baerts (NGI0) wrote:
>>> When adding a socket option support in MPTCP, both the get and set parts
>>> are supposed to be implemented.
>>>
>>> IPV6_V6ONLY support for the setsockopt part has been added a while ago,
>>> but it looks like the get part got forgotten. It should have been
>>> present as a way to verify a setting has been set as expected, and not
>>> to act differently from TCP or any other socket types.
>>>
>>> Not supporting this getsockopt(IPV6_V6ONLY) blocks some apps which want
>>> to check the default value, before doing extra actions. On Linux, the
>>> default value is 0, but this can be changed with the net.ipv6.bindv6only
>>> sysctl knob. On Windows, it is set to 1 by default. So supporting the
>>> get part, like for all other socket options, is important.
>>>
>>> Everything was in place to expose it, just the last step was missing.
>>> Only new code is added to cover this specific getsockopt(), that seems
>>> safe.
>>>
>>> Fixes: c9b95a135987 ("mptcp: support IPV6_V6ONLY setsockopt")
>>> Cc: stable@vger.kernel.org
>>> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/550
>>> Reviewed-by: Mat Martineau <martineau@kernel.org>
>>> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
>>
>> Hi Matthieu, all,
>>
>> TBH, I would lean towards this being net-next material rather than a fix
>> for net. But that notwithstanding this looks good to me.
> I understand. This patch and the next one target "net" because, with
> MPTCP, we try to mimic TCP when interacting with the userspace.
> 
> Not supporting "getsockopt(IPV6_V6ONLY)" breaks some legacy apps forced
> to use MPTCP instead of TCP. These apps apparently "strangely" check
> this "getsockopt(IPV6_V6ONLY)" before changing the behaviour with
> "setsockopt(IPV6_V6ONLY)" which is supported for a long time. The "get"
> part should have been added from the beginning, and I don't see this
> patch as a new feature. Because it simply sets an integer like most
> other "get" options, it seems better to target net and fix these apps
> ASAP rather than targeting net-next and delay this "safe" fix.
> 
> If that's OK, I would then prefer if these patches are applied in "net".
> Or they can be applied in "net-next" if we can keep their "Cc: stable"
> and "Fixes" tags, but that looks strange.

As per off-line discussion I'm going to apply only the first patch in
this series to net, and leave the other for net-next.

/P

Re: [PATCH net 2/3] mptcp: sockopt: fix getting IPV6_V6ONLY

[Simon Horman]

On Wed, Mar 19, 2025 at 05:26:35PM +0100, Matthieu Baerts wrote:
> Hi Simon,
> 
> Thank you for your review!
> 
> On 19/03/2025 16:38, Simon Horman wrote:
> > On Fri, Mar 14, 2025 at 09:11:32PM +0100, Matthieu Baerts (NGI0) wrote:
> >> When adding a socket option support in MPTCP, both the get and set parts
> >> are supposed to be implemented.
> >>
> >> IPV6_V6ONLY support for the setsockopt part has been added a while ago,
> >> but it looks like the get part got forgotten. It should have been
> >> present as a way to verify a setting has been set as expected, and not
> >> to act differently from TCP or any other socket types.
> >>
> >> Not supporting this getsockopt(IPV6_V6ONLY) blocks some apps which want
> >> to check the default value, before doing extra actions. On Linux, the
> >> default value is 0, but this can be changed with the net.ipv6.bindv6only
> >> sysctl knob. On Windows, it is set to 1 by default. So supporting the
> >> get part, like for all other socket options, is important.
> >>
> >> Everything was in place to expose it, just the last step was missing.
> >> Only new code is added to cover this specific getsockopt(), that seems
> >> safe.
> >>
> >> Fixes: c9b95a135987 ("mptcp: support IPV6_V6ONLY setsockopt")
> >> Cc: stable@vger.kernel.org
> >> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/550
> >> Reviewed-by: Mat Martineau <martineau@kernel.org>
> >> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
> > 
> > Hi Matthieu, all,
> > 
> > TBH, I would lean towards this being net-next material rather than a fix
> > for net. But that notwithstanding this looks good to me.
> I understand. This patch and the next one target "net" because, with
> MPTCP, we try to mimic TCP when interacting with the userspace.
> 
> Not supporting "getsockopt(IPV6_V6ONLY)" breaks some legacy apps forced
> to use MPTCP instead of TCP. These apps apparently "strangely" check
> this "getsockopt(IPV6_V6ONLY)" before changing the behaviour with
> "setsockopt(IPV6_V6ONLY)" which is supported for a long time. The "get"
> part should have been added from the beginning, and I don't see this
> patch as a new feature. Because it simply sets an integer like most
> other "get" options, it seems better to target net and fix these apps
> ASAP rather than targeting net-next and delay this "safe" fix.
> 
> If that's OK, I would then prefer if these patches are applied in "net".
> Or they can be applied in "net-next" if we can keep their "Cc: stable"
> and "Fixes" tags, but that looks strange.

Hi Matthieu,

Thanks for your detailed explanation.
With that in mind I agree that these seem appropriate for net.

[PATCH net 3/3] mptcp: sockopt: fix getting freebind & transparent

[Matthieu Baerts (NGI0)]

When adding a socket option support in MPTCP, both the get and set parts
are supposed to be implemented.

IP(V6)_FREEBIND and IP(V6)_TRANSPARENT support for the setsockopt part
has been added a while ago, but it looks like the get part got
forgotten. It should have been present as a way to verify a setting has
been set as expected, and not to act differently from TCP or any other
socket types.

Everything was in place to expose it, just the last step was missing.
Only new code is added to cover these specific getsockopt(), that seems
safe.

Fixes: c9406a23c116 ("mptcp: sockopt: add SOL_IP freebind & transparent options")
Cc: stable@vger.kernel.org
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
 net/mptcp/sockopt.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/net/mptcp/sockopt.c b/net/mptcp/sockopt.c
index 4b99eb796855e4578d14df90f9d1cc3f1cd5b8c7..3caa0a9d3b3885ce6399570f2d98a2e8f103638d 100644
--- a/net/mptcp/sockopt.c
+++ b/net/mptcp/sockopt.c
@@ -1419,6 +1419,12 @@ static int mptcp_getsockopt_v4(struct mptcp_sock *msk, int optname,
 	switch (optname) {
 	case IP_TOS:
 		return mptcp_put_int_option(msk, optval, optlen, READ_ONCE(inet_sk(sk)->tos));
+	case IP_FREEBIND:
+		return mptcp_put_int_option(msk, optval, optlen,
+				inet_test_bit(FREEBIND, sk));
+	case IP_TRANSPARENT:
+		return mptcp_put_int_option(msk, optval, optlen,
+				inet_test_bit(TRANSPARENT, sk));
 	case IP_BIND_ADDRESS_NO_PORT:
 		return mptcp_put_int_option(msk, optval, optlen,
 				inet_test_bit(BIND_ADDRESS_NO_PORT, sk));
@@ -1439,6 +1445,12 @@ static int mptcp_getsockopt_v6(struct mptcp_sock *msk, int optname,
 	case IPV6_V6ONLY:
 		return mptcp_put_int_option(msk, optval, optlen,
 					    sk->sk_ipv6only);
+	case IPV6_TRANSPARENT:
+		return mptcp_put_int_option(msk, optval, optlen,
+					    inet_test_bit(TRANSPARENT, sk));
+	case IPV6_FREEBIND:
+		return mptcp_put_int_option(msk, optval, optlen,
+					    inet_test_bit(FREEBIND, sk));
 	}
 
 	return -EOPNOTSUPP;

-- 
2.48.1

Re: [PATCH net 3/3] mptcp: sockopt: fix getting freebind & transparent

[Simon Horman]

On Fri, Mar 14, 2025 at 09:11:33PM +0100, Matthieu Baerts (NGI0) wrote:
> When adding a socket option support in MPTCP, both the get and set parts
> are supposed to be implemented.
> 
> IP(V6)_FREEBIND and IP(V6)_TRANSPARENT support for the setsockopt part
> has been added a while ago, but it looks like the get part got
> forgotten. It should have been present as a way to verify a setting has
> been set as expected, and not to act differently from TCP or any other
> socket types.
> 
> Everything was in place to expose it, just the last step was missing.
> Only new code is added to cover these specific getsockopt(), that seems
> safe.
> 
> Fixes: c9406a23c116 ("mptcp: sockopt: add SOL_IP freebind & transparent options")
> Cc: stable@vger.kernel.org
> Reviewed-by: Mat Martineau <martineau@kernel.org>
> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>

Hi Matthieu, all,

As per my comment on patch 2/3, I would lean towards this being net-next
material rather than a fix for net. But that notwithstanding this looks
good to me.

Reviewed-by: Simon Horman <horms@kernel.org>

Re: [PATCH net 0/3] mptcp: fix data stream corruption and missing sockopts

[patchwork-bot+netdevbpf]

Hello:

This series was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:

On Fri, 14 Mar 2025 21:11:30 +0100 you wrote:
> Here are 3 unrelated fixes for the net tree.
> 
> - Patch 1: fix data stream corruption when ending up not sending an
>   ADD_ADDR.
> 
> - Patch 2: fix missing getsockopt(IPV6_V6ONLY) support -- the set part
>   is supported.
> 
> [...]

Here is the summary with links:
  - [net,1/3] mptcp: Fix data stream corruption in the address announcement
    https://git.kernel.org/netdev/net/c/2c1f97a52cb8
  - [net,2/3] mptcp: sockopt: fix getting IPV6_V6ONLY
    (no matching commit)
  - [net,3/3] mptcp: sockopt: fix getting freebind & transparent
    (no matching commit)

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCH net 0/3] mptcp: fix data stream corruption and missing sockopts

[patchwork-bot+netdevbpf]

Hello:

This series was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:

On Fri, 14 Mar 2025 21:11:30 +0100 you wrote:
> Here are 3 unrelated fixes for the net tree.
> 
> - Patch 1: fix data stream corruption when ending up not sending an
>   ADD_ADDR.
> 
> - Patch 2: fix missing getsockopt(IPV6_V6ONLY) support -- the set part
>   is supported.
> 
> [...]

Here is the summary with links:
  - [net,1/3] mptcp: Fix data stream corruption in the address announcement
    (no matching commit)
  - [net,2/3] mptcp: sockopt: fix getting IPV6_V6ONLY
    https://git.kernel.org/netdev/net-next/c/8c3963375988
  - [net,3/3] mptcp: sockopt: fix getting freebind & transparent
    https://git.kernel.org/netdev/net-next/c/e2f4ac7bab22

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html