From: Arthur Mongodin <amongodin(a)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(a)vger.kernel.org
Suggested-by: Paolo Abeni <pabeni(a)redhat.com>
Signed-off-by: Arthur Mongodin <amongodin(a)randorisec.fr>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org>
[ Matt: the commit message has been updated: long lines splits and some
clarifications. ]
Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)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
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(a)vger.kernel.org
Reviewed-by: Mat Martineau <martineau(a)kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)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
Dear Greg,
I see that the review for 6.6.84-rc1 hasn't started yet, but as it was
already available on [1], our CI has already tried to built it for ia64
in the morning. Unfortunately that failed - I assume due to the
following **missing** upstream commit:
https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/comm…
[1]: https://web.git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.…
Build failure (see [2]):
```
[...]
CC drivers/video/fbdev/core/fbcon.o
drivers/video/fbdev/core/fbcon.c: In function 'fb_console_setup':
drivers/video/fbdev/core/fbcon.c:478:33: error: 'fb_center_logo' undeclared (first use in this function); did you mean 'fb_prepare_logo'?
478 | fb_center_logo = true;
| ^~~~~~~~~~~~~~
| fb_prepare_logo
drivers/video/fbdev/core/fbcon.c:478:33: note: each undeclared identifier is reported only once for each function it appears in
drivers/video/fbdev/core/fbcon.c:485:33: error: 'fb_logo_count' undeclared (first use in this function); did you mean 'file_count'?
485 | fb_logo_count = simple_strtol(options, &options, 0);
| ^~~~~~~~~~~~~
| file_count
make[8]: *** [scripts/Makefile.build:243: drivers/video/fbdev/core/fbcon.o] Error 1
[...]
```
[2]: https://github.com/linux-ia64/linux-stable-rc/actions/runs/13914712427/job/…
[3] (fa671e4f1556e2c18e5443f777a75ae041290068 upstream) includes
definitions for these variables, but they are guarded by CONFIG_LOGO.
But in `drivers/video/fbdev/core/fbcon.c` those variables are used
unguarded with 6.6.84-rc1. The above upstream commit (8887086) fixes
that IIUC. Not build-tested yet, though.
[3]: https://web.git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.…
Cheers,
Frank
Hi again,
I would appreciate your feedback on the proposal I sent earlier.
Looking forward to your response.
Best regards,
Kristina
________________________________
From: Kristina Williams
Sent: 17 March 2025 12:29
To: linux-stable-mirror(a)lists.linaro.org<mailto:linux-stable-mirror@lists.linaro.org>
Subject: Transform your business
Hi there,
Would you like an updated contact list of Real Estate CRM Software users and customers?
We can also provide contact lists for users and customers of the following companies:
* AppFolio
* RealPage
* Buildium
* CoreLogic
* Yardi Voyager
* Kissflow CRM
* Pipedrive
* HubSpot CRM Service and more...
Please specify the target technology users and geographical areas of interest, so we can provide relevant information accordingly.
Kind regards,
Kristina Williams
Lead Specialist
To unsubscribe from future emails, simply reply with Stop.
Hi Sasha,
On Sat, Mar 15, 2025 at 09:34:40AM -0400, Sasha Levin wrote:
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable(a)vger.kernel.org> know about it.
This fix is unfortunately buggy (schedule in atomic context). There is a
fixup patch which would be necessary alongside this patch:
f13409bb3f91 ("nvme-fc: rely on state transitions to handle connectivity
loss")
Thanks,
Daniel
> commit e0cdcd023334a757ae78a43d2fa8909dcc72ec56
> Author: Daniel Wagner <wagi(a)kernel.org>
> Date: Thu Jan 9 14:30:49 2025 +0100
>
> nvme-fc: do not ignore connectivity loss during connecting