Skip to content

[LTS 9.2] mptcp CVEs {CVE-2024-57882,CVE-2024-53122} + bugfix #186

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Apr 1, 2025

Conversation

PlaidCat
Copy link
Collaborator

@PlaidCat PlaidCat commented Mar 31, 2025

ontext this has 2 CVES and a bug fix to the same commit as CVE-2024-57882

Despite MPTCP (MultiPath TCP) is disabled by default we do know that some customers use MultiPath in various ways and can be incredibly difficult to trouble shoot so we're address some additional CVEs outside our priority matrix to make this a little bit better.

Commit Merge Conflicts

a562bf3
A recent change f410cbe introduced in v6.10-rc1 tcp annotate data-races around tp->window_clamp had some fuzz due to the WRITE_ONCE and keep the original code. No conflicts in merged in code.

BUILD

/mnt/code/kernel-src-tree-build
no .config file found, moving on
[TIMER]{MRPROPER}: 0s
x86_64 architecture detected, copying config
'configs/kernel-5.14.0-x86_64.config' -> '.config'
Setting Local Version for build
CONFIG_LOCALVERSION="-_jmaple__ciqlts9_2-f51d4f2003d3"
Making olddefconfig
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/confdata.o
  HOSTCC  scripts/kconfig/expr.o
  LEX     scripts/kconfig/lexer.lex.c
  YACC    scripts/kconfig/parser.tab.[ch]
  HOSTCC  scripts/kconfig/lexer.lex.o
  HOSTCC  scripts/kconfig/menu.o
  HOSTCC  scripts/kconfig/parser.tab.o
  HOSTCC  scripts/kconfig/preprocess.o
  HOSTCC  scripts/kconfig/symbol.o
  HOSTCC  scripts/kconfig/util.o
  HOSTLD  scripts/kconfig/conf
#
# configuration written to .config
#
Starting Build
  SYSHDR  arch/x86/include/generated/uapi/asm/unistd_32.h
  SYSHDR  arch/x86/include/generated/uapi/asm/unistd_64.h

[SNIP]

  LD [M]  virt/lib/irqbypass.ko
  BTF [M] sound/xen/snd_xen_front.ko
  BTF [M] virt/lib/irqbypass.ko
[TIMER]{BUILD}: 1392s
Making Modules
  INSTALL /lib/modules/5.14.0-_jmaple__ciqlts9_2-f51d4f2003d3+/kernel/arch/x86/crypto/blake2s-x86_64.ko
  STRIP   /lib/modules/5.14.0-_jmaple__ciqlts9_2-f51d4f2003d3+/kernel/arch/x86/crypto/blake2s-x86_64.ko

[SNIP]

  STRIP   /lib/modules/5.14.0-_jmaple__ciqlts9_2-f51d4f2003d3+/kernel/virt/lib/irqbypass.ko
  SIGN    /lib/modules/5.14.0-_jmaple__ciqlts9_2-f51d4f2003d3+/kernel/virt/lib/irqbypass.ko
  DEPMOD  /lib/modules/5.14.0-_jmaple__ciqlts9_2-f51d4f2003d3+
[TIMER]{MODULES}: 35s
Making Install
sh ./arch/x86/boot/install.sh \
        5.14.0-_jmaple__ciqlts9_2-f51d4f2003d3+ arch/x86/boot/bzImage \
        System.map "/boot"
[TIMER]{INSTALL}: 23s
Checking kABI
kABI check passed
Setting Default Kernel to /boot/vmlinuz-5.14.0-_jmaple__ciqlts9_2-f51d4f2003d3+ and Index to 2
Hopefully Grub2.0 took everything ... rebooting after time metrices
[TIMER]{MRPROPER}: 0s
[TIMER]{BUILD}: 1392s
[TIMER]{MODULES}: 35s
[TIMER]{INSTALL}: 23s
[TIMER]{TOTAL} 1453s
Rebooting in 10 seconds

Kernel Self Tests

For what ever reason 1 iteration of kselftest from the rpm install bail out early every single time afterwards and the rebuidl would always bail at userfaultfsd which it only just started recently running (looking through old version it would skip MM selftest)
This comparison is between a default kselftest run and a manual compile one.
Both are about 88-90% ^ok rate (pretty common)

$ grep '^ok ' kernel_5.14.0-284.30.1.el9_2.92ciq_lts.4.1.x86_64_iteration_1.log | wc -l
205
$ grep '^not ok ' kernel_5.14.0-_jmaple__ciqlts9_2-f51d4f2003d3+_manual_selftest.log | wc -l
34

$ grep '^ok ' kernel_5.14.0-_jmaple__ciqlts9_2-f51d4f2003d3+_manual_selftest.log | wc -l
264
$ grep '^not ok ' kernel_5.14.0-_jmaple__ciqlts9_2-f51d4f2003d3+_manual_selftest.log | wc -l
34

6.12.15-_jmaple__ciq-6.12.y-b3fa7c3036f6+.kselftest.log
6.12.15-_jmaple__sb_ciq-6.12.y-4e5411d06b62+.kselftest.log

jira VULN-46443
cve CVE-2024-53122
commit-author Paolo Abeni <[email protected]>
commit ce7356a
upstream-diff A recent change f410cbe introduced in v6.10-rc1
              tcp annotate data-races around tp->window_clamp
	      had some fuzz due to the WRITE_ONCE and keep the
	      original code.  No conflicts in merged in code.

Additional active subflows - i.e. created by the in kernel path
manager - are included into the subflow list before starting the
3whs.

A racing recvmsg() spooling data received on an already established
subflow would unconditionally call tcp_cleanup_rbuf() on all the
current subflows, potentially hitting a divide by zero error on
the newly created ones.

Explicitly check that the subflow is in a suitable state before
invoking tcp_cleanup_rbuf().

Fixes: c76c695 ("mptcp: call tcp_cleanup_rbuf on subflows")
	Signed-off-by: Paolo Abeni <[email protected]>
	Reviewed-by: Matthieu Baerts (NGI0) <[email protected]>
Link: https://patch.msgid.link/02374660836e1b52afc91966b7535c8c5f7bafb0.1731060874.git.pabeni@redhat.com
	Signed-off-by: Jakub Kicinski <[email protected]>
(cherry picked from commit ce7356a)
	Signed-off-by: Jonathan Maple <[email protected]>
jira VULN-41988
cve CVE-2024-57882
commit-author Paolo Abeni <[email protected]>
commit cbb26f7

Syzbot reported the following splat:

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 1 UID: 0 PID: 5836 Comm: sshd Not tainted 6.13.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024
RIP: 0010:_compound_head include/linux/page-flags.h:242 [inline]
RIP: 0010:put_page+0x23/0x260 include/linux/mm.h:1552
Code: 90 90 90 90 90 90 90 55 41 57 41 56 53 49 89 fe 48 bd 00 00 00 00 00 fc ff df e8 f8 5e 12 f8 49 8d 5e 08 48 89 d8 48 c1 e8 03 <80> 3c 28 00 74 08 48 89 df e8 8f c7 78 f8 48 8b 1b 48 89 de 48 83
RSP: 0000:ffffc90003916c90 EFLAGS: 00010202
RAX: 0000000000000001 RBX: 0000000000000008 RCX: ffff888030458000
RDX: 0000000000000100 RSI: 0000000000000000 RDI: 0000000000000000
RBP: dffffc0000000000 R08: ffffffff898ca81d R09: 1ffff110054414ac
R10: dffffc0000000000 R11: ffffed10054414ad R12: 0000000000000007
R13: ffff88802a20a542 R14: 0000000000000000 R15: 0000000000000000
FS:  00007f34f496e800(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f9d6ec9ec28 CR3: 000000004d260000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 skb_page_unref include/linux/skbuff_ref.h:43 [inline]
 __skb_frag_unref include/linux/skbuff_ref.h:56 [inline]
 skb_release_data+0x483/0x8a0 net/core/skbuff.c:1119
 skb_release_all net/core/skbuff.c:1190 [inline]
 __kfree_skb+0x55/0x70 net/core/skbuff.c:1204
 tcp_clean_rtx_queue net/ipv4/tcp_input.c:3436 [inline]
 tcp_ack+0x2442/0x6bc0 net/ipv4/tcp_input.c:4032
 tcp_rcv_state_process+0x8eb/0x44e0 net/ipv4/tcp_input.c:6805
 tcp_v4_do_rcv+0x77d/0xc70 net/ipv4/tcp_ipv4.c:1939
 tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2351
 ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205
 ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233
 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314
 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314
 __netif_receive_skb_one_core net/core/dev.c:5672 [inline]
 __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5785
 process_backlog+0x662/0x15b0 net/core/dev.c:6117
 __napi_poll+0xcb/0x490 net/core/dev.c:6883
 napi_poll net/core/dev.c:6952 [inline]
 net_rx_action+0x89b/0x1240 net/core/dev.c:7074
 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561
 __do_softirq kernel/softirq.c:595 [inline]
 invoke_softirq kernel/softirq.c:435 [inline]
 __irq_exit_rcu+0xf7/0x220 kernel/softirq.c:662
 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678
 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline]
 sysvec_apic_timer_interrupt+0x57/0xc0 arch/x86/kernel/apic/apic.c:1049
 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702
RIP: 0033:0x7f34f4519ad5
Code: 85 d2 74 0d 0f 10 02 48 8d 54 24 20 0f 11 44 24 20 64 8b 04 25 18 00 00 00 85 c0 75 27 41 b8 08 00 00 00 b8 0f 01 00 00 0f 05 <48> 3d 00 f0 ff ff 76 75 48 8b 15 24 73 0d 00 f7 d8 64 89 02 48 83
RSP: 002b:00007ffec5b32ce0 EFLAGS: 00000246
RAX: 0000000000000001 RBX: 00000000000668a0 RCX: 00007f34f4519ad5
RDX: 00007ffec5b32d00 RSI: 0000000000000004 RDI: 0000564f4bc6cae0
RBP: 0000564f4bc6b5a0 R08: 0000000000000008 R09: 0000000000000000
R10: 00007ffec5b32de8 R11: 0000000000000246 R12: 0000564f48ea8aa4
R13: 0000000000000001 R14: 0000564f48ea93e8 R15: 00007ffec5b32d68
 </TASK>

Eric noted a probable shinfo->nr_frags corruption, which indeed
occurs.

The root cause is a buggy MPTCP option len computation in some
circumstances: the ADD_ADDR option should be mutually exclusive
with DSS since the blamed commit.

Still, mptcp_established_options_add_addr() tries to set the
relevant info in mptcp_out_options, if the remaining space is
large enough even when DSS is present.

Since the ADD_ADDR infos and the DSS share the same union
fields, adding first corrupts the latter. In the worst-case
scenario, such corruption increases the DSS binary layout,
exceeding the computed length and possibly overwriting the
skb shared info.

Address the issue by enforcing mutual exclusion in
mptcp_established_options_add_addr(), too.

	Cc: [email protected]
	Reported-by: [email protected]
Closes: multipath-tcp/mptcp_net-next#538
Fixes: 1bff1e4 ("mptcp: optimize out option generation")
	Signed-off-by: Paolo Abeni <[email protected]>
	Reviewed-by: Matthieu Baerts (NGI0) <[email protected]>
	Reviewed-by: Eric Dumazet <[email protected]>
Link: https://patch.msgid.link/025d9df8cde3c9a557befc47e9bc08fbbe3476e5.1734771049.git.pabeni@redhat.com
	Signed-off-by: Jakub Kicinski <[email protected]>
(cherry picked from commit cbb26f7)
	Signed-off-by: Jonathan Maple <[email protected]>
bugfix related to other mptcp CVEs
commit-author Arthur Mongodin <[email protected]>
commit 2c1f97a

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: 1bff1e4 ("mptcp: optimize out option generation")
	Cc: [email protected]
	Suggested-by: Paolo Abeni <[email protected]>
	Signed-off-by: Arthur Mongodin <[email protected]>
	Reviewed-by: Matthieu Baerts (NGI0) <[email protected]>
[ Matt: the commit message has been updated: long lines splits and some
  clarifications. ]
	Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
	Reviewed-by: Simon Horman <[email protected]>
Link: https://patch.msgid.link/20250314-net-mptcp-fix-data-stream-corr-sockopt-v1-1-122dbb249db3@kernel.org
	Signed-off-by: Paolo Abeni <[email protected]>
(cherry picked from commit 2c1f97a)
	Signed-off-by: Jonathan Maple <[email protected]>
@PlaidCat PlaidCat self-assigned this Mar 31, 2025
@PlaidCat PlaidCat marked this pull request as ready for review March 31, 2025 21:01
Copy link
Collaborator

@bmastbergen bmastbergen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🥌

Copy link

@thefossguy-ciq thefossguy-ciq left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚤

@PlaidCat PlaidCat merged commit cd572d5 into ciqlts9_2 Apr 1, 2025
3 checks passed
@PlaidCat PlaidCat deleted the {jmaple}_ciqlts9_2 branch April 1, 2025 15:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants