net/mptcp/protocol.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
From: Jiayuan Chen <jiayuan.chen@linux.dev>
commit c77b3b79a92e3345aa1ee296180d1af4e7031f8f upstream.
The sockmap feature allows bpf syscall from userspace, or based
on bpf sockops, replacing the sk_prot of sockets during protocol stack
processing with sockmap's custom read/write interfaces.
'''
tcp_rcv_state_process()
syn_recv_sock()/subflow_syn_recv_sock()
tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB)
bpf_skops_established <== sockops
bpf_sock_map_update(sk) <== call bpf helper
tcp_bpf_update_proto() <== update sk_prot
'''
When the server has MPTCP enabled but the client sends a TCP SYN
without MPTCP, subflow_syn_recv_sock() performs a fallback on the
subflow, replacing the subflow sk's sk_prot with the native sk_prot.
'''
subflow_syn_recv_sock()
subflow_ulp_fallback()
subflow_drop_ctx()
mptcp_subflow_ops_undo_override()
'''
Then, this subflow can be normally used by sockmap, which replaces the
native sk_prot with sockmap's custom sk_prot. The issue occurs when the
user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops().
Here, it uses sk->sk_prot to compare with the native sk_prot, but this
is incorrect when sockmap is used, as we may incorrectly set
sk->sk_socket->ops.
This fix uses the more generic sk_family for the comparison instead.
Additionally, this also prevents a WARNING from occurring:
result from ./scripts/decode_stacktrace.sh:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \
(net/mptcp/protocol.c:4005)
Modules linked in:
...
PKRU: 55555554
Call Trace:
<TASK>
do_accept (net/socket.c:1989)
__sys_accept4 (net/socket.c:2028 net/socket.c:2057)
__x64_sys_accept (net/socket.c:2067)
x64_sys_call (arch/x86/entry/syscall_64.c:41)
do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
RIP: 0033:0x7f87ac92b83d
---[ end trace 0000000000000000 ]---
Fixes: 0b4f33def7bb ("mptcp: fix tcp fallback crash")
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Cc: <stable@vger.kernel.org>
Link: https://patch.msgid.link/20251111060307.194196-3-jiayuan.chen@linux.dev
[ Conflicts in protocol.c, because commit 8e2b8a9fa512 ("mptcp: don't
overwrite sock_ops in mptcp_is_tcpsk()") is not in this version. It
changes the logic on how and where the sock_ops is overridden in case
of passive fallback. To fix this, mptcp_is_tcpsk() is modified to use
the family, but first, a check of the protocol is required to continue
returning 'false' in case of MPTCP socket. ]
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
net/mptcp/protocol.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index f89de0f7b3e5..98fd4ffe6f11 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -77,8 +77,13 @@ static u64 mptcp_wnd_end(const struct mptcp_sock *msk)
static bool mptcp_is_tcpsk(struct sock *sk)
{
struct socket *sock = sk->sk_socket;
+ unsigned short family;
- if (unlikely(sk->sk_prot == &tcp_prot)) {
+ if (likely(sk->sk_protocol == IPPROTO_MPTCP))
+ return false;
+
+ family = READ_ONCE(sk->sk_family);
+ if (unlikely(family == AF_INET)) {
/* we are being invoked after mptcp_accept() has
* accepted a non-mp-capable flow: sk is a tcp_sk,
* not an mptcp one.
@@ -89,7 +94,7 @@ static bool mptcp_is_tcpsk(struct sock *sk)
sock->ops = &inet_stream_ops;
return true;
#if IS_ENABLED(CONFIG_MPTCP_IPV6)
- } else if (unlikely(sk->sk_prot == &tcpv6_prot)) {
+ } else if (unlikely(family == AF_INET6)) {
sock->ops = &inet6_stream_ops;
return true;
#endif
--
2.51.0December 1, 2025 at 19:27, "Matthieu Baerts (NGI0)" <matttbe@kernel.org mailto:matttbe@kernel.org?to=%22Matthieu%20Baerts%20(NGI0)%22%20%3Cmatttbe%40kernel.org%3E > wrote:
>
> From: Jiayuan Chen <jiayuan.chen@linux.dev>
>
> commit c77b3b79a92e3345aa1ee296180d1af4e7031f8f upstream.
>
> The sockmap feature allows bpf syscall from userspace, or based
> on bpf sockops, replacing the sk_prot of sockets during protocol stack
> processing with sockmap's custom read/write interfaces.
> '''
> tcp_rcv_state_process()
> syn_recv_sock()/subflow_syn_recv_sock()
> tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB)
> bpf_skops_established <== sockops
> bpf_sock_map_update(sk) <== call bpf helper
> tcp_bpf_update_proto() <== update sk_prot
> '''
>
> When the server has MPTCP enabled but the client sends a TCP SYN
> without MPTCP, subflow_syn_recv_sock() performs a fallback on the
> subflow, replacing the subflow sk's sk_prot with the native sk_prot.
> '''
> subflow_syn_recv_sock()
> subflow_ulp_fallback()
> subflow_drop_ctx()
> mptcp_subflow_ops_undo_override()
> '''
>
> Then, this subflow can be normally used by sockmap, which replaces the
> native sk_prot with sockmap's custom sk_prot. The issue occurs when the
> user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops().
> Here, it uses sk->sk_prot to compare with the native sk_prot, but this
> is incorrect when sockmap is used, as we may incorrectly set
> sk->sk_socket->ops.
>
> This fix uses the more generic sk_family for the comparison instead.
>
> Additionally, this also prevents a WARNING from occurring:
>
> result from ./scripts/decode_stacktrace.sh:
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \
> (net/mptcp/protocol.c:4005)
> Modules linked in:
> ...
>
> PKRU: 55555554
> Call Trace:
> <TASK>
> do_accept (net/socket.c:1989)
> __sys_accept4 (net/socket.c:2028 net/socket.c:2057)
> __x64_sys_accept (net/socket.c:2067)
> x64_sys_call (arch/x86/entry/syscall_64.c:41)
> do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
> RIP: 0033:0x7f87ac92b83d
>
> ---[ end trace 0000000000000000 ]---
>
> Fixes: 0b4f33def7bb ("mptcp: fix tcp fallback crash")
> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
> Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
> Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
> Cc: <stable@vger.kernel.org>
> Link: https://patch.msgid.link/20251111060307.194196-3-jiayuan.chen@linux.dev
> [ Conflicts in protocol.c, because commit 8e2b8a9fa512 ("mptcp: don't
> overwrite sock_ops in mptcp_is_tcpsk()") is not in this version. It
> changes the logic on how and where the sock_ops is overridden in case
> of passive fallback. To fix this, mptcp_is_tcpsk() is modified to use
> the family, but first, a check of the protocol is required to continue
> returning 'false' in case of MPTCP socket. ]
> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
> ---
> net/mptcp/protocol.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
> index f89de0f7b3e5..98fd4ffe6f11 100644
> --- a/net/mptcp/protocol.c
> +++ b/net/mptcp/protocol.c
> @@ -77,8 +77,13 @@ static u64 mptcp_wnd_end(const struct mptcp_sock *msk)
> static bool mptcp_is_tcpsk(struct sock *sk)
> {
> struct socket *sock = sk->sk_socket;
> + unsigned short family;
>
> - if (unlikely(sk->sk_prot == &tcp_prot)) {
> + if (likely(sk->sk_protocol == IPPROTO_MPTCP))
> + return false;
> +
> + family = READ_ONCE(sk->sk_family);
> + if (unlikely(family == AF_INET)) {
> /* we are being invoked after mptcp_accept() has
> * accepted a non-mp-capable flow: sk is a tcp_sk,
> * not an mptcp one.
> @@ -89,7 +94,7 @@ static bool mptcp_is_tcpsk(struct sock *sk)
> sock->ops = &inet_stream_ops;
> return true;
> #if IS_ENABLED(CONFIG_MPTCP_IPV6)
> - } else if (unlikely(sk->sk_prot == &tcpv6_prot)) {
> + } else if (unlikely(family == AF_INET6)) {
> sock->ops = &inet6_stream_ops;
> return true;
> #endif
> --
> 2.51.0
>
Thanks — I happened to have a 5.15 environment, and I’ve successfully tested
the patch there. I believe 5.10 should behave the same way.
Before applying the patch, the following panic occurred. After applying it,
the panic disappeared. I think this is sufficient to confirm the fix works
for both 5.15 and 5.10.
BUG: unable to handle page fault for address: 0000000dd85a1764
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] SMP PTI
CPU: 0 PID: 373 Comm: test_progs Not tainted 5.15.189+ #11
RIP: 0010:mptcp_stream_accept+0x118/0x3c0
RSP: 0018:ffffc90000907ad8 EFLAGS: 00010246
RAX: 0000000dd85a129c RBX: ffff88800c52c000 RCX: 0000000000000000
RDX: 00030d4000030d40 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffc90000907b30 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8880050ada00
R13: ffff888005099d40 R14: ffff888007368670 R15: ffff888007368000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000dd85a1764 CR3: 0000000006e20004 CR4: 0000000000770ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
<TASK>
? apparmor_socket_accept+0x1e/0x30
do_accept+0x12a/0x1b0
__sys_accept4_file+0x55/0xb0
__sys_accept4+0x62/0xc0
__x64_sys_accept+0x1b/0x30
x64_sys_call+0x1a57/0x2190
Hi Jiayuan,
On 01/12/2025 13:08, Jiayuan Chen wrote:
> December 1, 2025 at 19:27, "Matthieu Baerts (NGI0)" <matttbe@kernel.org mailto:matttbe@kernel.org?to=%22Matthieu%20Baerts%20(NGI0)%22%20%3Cmatttbe%40kernel.org%3E > wrote:
>
>
>>
>> From: Jiayuan Chen <jiayuan.chen@linux.dev>
>>
>> commit c77b3b79a92e3345aa1ee296180d1af4e7031f8f upstream.
>>
>> The sockmap feature allows bpf syscall from userspace, or based
>> on bpf sockops, replacing the sk_prot of sockets during protocol stack
>> processing with sockmap's custom read/write interfaces.
>> '''
>> tcp_rcv_state_process()
>> syn_recv_sock()/subflow_syn_recv_sock()
>> tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB)
>> bpf_skops_established <== sockops
>> bpf_sock_map_update(sk) <== call bpf helper
>> tcp_bpf_update_proto() <== update sk_prot
>> '''
>>
>> When the server has MPTCP enabled but the client sends a TCP SYN
>> without MPTCP, subflow_syn_recv_sock() performs a fallback on the
>> subflow, replacing the subflow sk's sk_prot with the native sk_prot.
>> '''
>> subflow_syn_recv_sock()
>> subflow_ulp_fallback()
>> subflow_drop_ctx()
>> mptcp_subflow_ops_undo_override()
>> '''
>>
>> Then, this subflow can be normally used by sockmap, which replaces the
>> native sk_prot with sockmap's custom sk_prot. The issue occurs when the
>> user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops().
>> Here, it uses sk->sk_prot to compare with the native sk_prot, but this
>> is incorrect when sockmap is used, as we may incorrectly set
>> sk->sk_socket->ops.
>>
>> This fix uses the more generic sk_family for the comparison instead.
>>
>> Additionally, this also prevents a WARNING from occurring:
>>
>> result from ./scripts/decode_stacktrace.sh:
>> ------------[ cut here ]------------
>> WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \
>> (net/mptcp/protocol.c:4005)
>> Modules linked in:
>> ...
>>
>> PKRU: 55555554
>> Call Trace:
>> <TASK>
>> do_accept (net/socket.c:1989)
>> __sys_accept4 (net/socket.c:2028 net/socket.c:2057)
>> __x64_sys_accept (net/socket.c:2067)
>> x64_sys_call (arch/x86/entry/syscall_64.c:41)
>> do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
>> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
>> RIP: 0033:0x7f87ac92b83d
>>
>> ---[ end trace 0000000000000000 ]---
>>
>> Fixes: 0b4f33def7bb ("mptcp: fix tcp fallback crash")
>> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
>> Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
>> Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
>> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
>> Cc: <stable@vger.kernel.org>
>> Link: https://patch.msgid.link/20251111060307.194196-3-jiayuan.chen@linux.dev
>> [ Conflicts in protocol.c, because commit 8e2b8a9fa512 ("mptcp: don't
>> overwrite sock_ops in mptcp_is_tcpsk()") is not in this version. It
>> changes the logic on how and where the sock_ops is overridden in case
>> of passive fallback. To fix this, mptcp_is_tcpsk() is modified to use
>> the family, but first, a check of the protocol is required to continue
>> returning 'false' in case of MPTCP socket. ]
>> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
>> ---
>> net/mptcp/protocol.c | 9 +++++++--
>> 1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
>> index f89de0f7b3e5..98fd4ffe6f11 100644
>> --- a/net/mptcp/protocol.c
>> +++ b/net/mptcp/protocol.c
>> @@ -77,8 +77,13 @@ static u64 mptcp_wnd_end(const struct mptcp_sock *msk)
>> static bool mptcp_is_tcpsk(struct sock *sk)
>> {
>> struct socket *sock = sk->sk_socket;
>> + unsigned short family;
>>
>> - if (unlikely(sk->sk_prot == &tcp_prot)) {
>> + if (likely(sk->sk_protocol == IPPROTO_MPTCP))
>> + return false;
>> +
>> + family = READ_ONCE(sk->sk_family);
>> + if (unlikely(family == AF_INET)) {
>> /* we are being invoked after mptcp_accept() has
>> * accepted a non-mp-capable flow: sk is a tcp_sk,
>> * not an mptcp one.
>> @@ -89,7 +94,7 @@ static bool mptcp_is_tcpsk(struct sock *sk)
>> sock->ops = &inet_stream_ops;
>> return true;
>> #if IS_ENABLED(CONFIG_MPTCP_IPV6)
>> - } else if (unlikely(sk->sk_prot == &tcpv6_prot)) {
>> + } else if (unlikely(family == AF_INET6)) {
>> sock->ops = &inet6_stream_ops;
>> return true;
>> #endif
>> --
>> 2.51.0
>>
>
> Thanks — I happened to have a 5.15 environment, and I’ve successfully tested
> the patch there. I believe 5.10 should behave the same way.
>
>
> Before applying the patch, the following panic occurred. After applying it,
> the panic disappeared. I think this is sufficient to confirm the fix works
> for both 5.15 and 5.10.
Thank you for having checked on v5.15 as well!
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
This is a note to let you know that I've just added the patch titled
mptcp: Fix proto fallback detection with BPF
to the 5.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
mptcp-fix-proto-fallback-detection-with-bpf.patch
and it can be found in the queue-5.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
From stable+bounces-197759-greg=kroah.com@vger.kernel.org Mon Dec 1 12:31:55 2025
From: "Matthieu Baerts (NGI0)" <matttbe@kernel.org>
Date: Mon, 1 Dec 2025 12:27:13 +0100
Subject: mptcp: Fix proto fallback detection with BPF
To: stable@vger.kernel.org, gregkh@linuxfoundation.org
Cc: MPTCP Upstream <mptcp@lists.linux.dev>, Jiayuan Chen <jiayuan.chen@linux.dev>, Martin KaFai Lau <martin.lau@kernel.org>, Jakub Sitnicki <jakub@cloudflare.com>, "Matthieu Baerts (NGI0)" <matttbe@kernel.org>
Message-ID: <20251201112712.3573321-2-matttbe@kernel.org>
From: Jiayuan Chen <jiayuan.chen@linux.dev>
commit c77b3b79a92e3345aa1ee296180d1af4e7031f8f upstream.
The sockmap feature allows bpf syscall from userspace, or based
on bpf sockops, replacing the sk_prot of sockets during protocol stack
processing with sockmap's custom read/write interfaces.
'''
tcp_rcv_state_process()
syn_recv_sock()/subflow_syn_recv_sock()
tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB)
bpf_skops_established <== sockops
bpf_sock_map_update(sk) <== call bpf helper
tcp_bpf_update_proto() <== update sk_prot
'''
When the server has MPTCP enabled but the client sends a TCP SYN
without MPTCP, subflow_syn_recv_sock() performs a fallback on the
subflow, replacing the subflow sk's sk_prot with the native sk_prot.
'''
subflow_syn_recv_sock()
subflow_ulp_fallback()
subflow_drop_ctx()
mptcp_subflow_ops_undo_override()
'''
Then, this subflow can be normally used by sockmap, which replaces the
native sk_prot with sockmap's custom sk_prot. The issue occurs when the
user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops().
Here, it uses sk->sk_prot to compare with the native sk_prot, but this
is incorrect when sockmap is used, as we may incorrectly set
sk->sk_socket->ops.
This fix uses the more generic sk_family for the comparison instead.
Additionally, this also prevents a WARNING from occurring:
result from ./scripts/decode_stacktrace.sh:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \
(net/mptcp/protocol.c:4005)
Modules linked in:
...
PKRU: 55555554
Call Trace:
<TASK>
do_accept (net/socket.c:1989)
__sys_accept4 (net/socket.c:2028 net/socket.c:2057)
__x64_sys_accept (net/socket.c:2067)
x64_sys_call (arch/x86/entry/syscall_64.c:41)
do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
RIP: 0033:0x7f87ac92b83d
---[ end trace 0000000000000000 ]---
Fixes: 0b4f33def7bb ("mptcp: fix tcp fallback crash")
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Cc: <stable@vger.kernel.org>
Link: https://patch.msgid.link/20251111060307.194196-3-jiayuan.chen@linux.dev
[ Conflicts in protocol.c, because commit 8e2b8a9fa512 ("mptcp: don't
overwrite sock_ops in mptcp_is_tcpsk()") is not in this version. It
changes the logic on how and where the sock_ops is overridden in case
of passive fallback. To fix this, mptcp_is_tcpsk() is modified to use
the family, but first, a check of the protocol is required to continue
returning 'false' in case of MPTCP socket. ]
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/mptcp/protocol.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -77,8 +77,13 @@ static u64 mptcp_wnd_end(const struct mp
static bool mptcp_is_tcpsk(struct sock *sk)
{
struct socket *sock = sk->sk_socket;
+ unsigned short family;
- if (unlikely(sk->sk_prot == &tcp_prot)) {
+ if (likely(sk->sk_protocol == IPPROTO_MPTCP))
+ return false;
+
+ family = READ_ONCE(sk->sk_family);
+ if (unlikely(family == AF_INET)) {
/* we are being invoked after mptcp_accept() has
* accepted a non-mp-capable flow: sk is a tcp_sk,
* not an mptcp one.
@@ -89,7 +94,7 @@ static bool mptcp_is_tcpsk(struct sock *
sock->ops = &inet_stream_ops;
return true;
#if IS_ENABLED(CONFIG_MPTCP_IPV6)
- } else if (unlikely(sk->sk_prot == &tcpv6_prot)) {
+ } else if (unlikely(family == AF_INET6)) {
sock->ops = &inet6_stream_ops;
return true;
#endif
Patches currently in stable-queue which might be from matttbe@kernel.org are
queue-5.15/x86-boot-compile-boot-code-with-std-gnu11-too.patch
queue-5.15/mptcp-disallow-mptcp-subflows-from-sockmap.patch
queue-5.15/revert-docs-process-howto-replace-c89-with-c11.patch
queue-5.15/mptcp-fix-race-condition-in-mptcp_schedule_work.patch
queue-5.15/mptcp-restore-window-probe.patch
queue-5.15/mptcp-fix-proto-fallback-detection-with-bpf.patch
queue-5.15/mptcp-do-not-fallback-when-ooo-is-present.patch
queue-5.15/arch-back-to-std-gnu89-in-v5.18.patch
queue-5.15/selftests-mptcp-join-rm-set-backup-flag.patch
queue-5.15/selftests-mptcp-connect-fix-fallback-note-due-to-ooo.patch
queue-5.15/mptcp-fix-ack-generation-for-fallback-msk.patch
queue-5.15/mptcp-pm-in-kernel-c-flag-handle-late-add_addr.patch
queue-5.15/mptcp-fix-premature-close-in-case-of-fallback.patch
queue-5.15/mptcp-fix-a-race-in-mptcp_pm_del_add_timer.patch
queue-5.15/gcov-add-support-for-gcc-15.patch
queue-5.15/mptcp-avoid-unneeded-subflow-level-drops.patch© 2016 - 2025 Red Hat, Inc.