Look up another CVE · open CVE-2026-43029 in the interactive tracker

CVE-2026-43029

mptcp: fix soft lockup in mptcp_recvmsg()

7.5 EPSS 0.5% AV:N

Published 2026-05-01 (6 months ago) by the Linux kernel CNA. Subsystem net/mptcp. Debian urgency: unimportant.

What to do, per Debian release

Debian's own status for CVE-2026-43029 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source

Release	Status	Version	What this means
Debian 12bookworm	not affected	6.1.190-1	Nothing to do. bookworm never shipped the vulnerable code.
Debian 13trixie	vulnerable	6.12.113-1	No fix published anywhere yet, neither in Debian nor upstream for the series trixie tracks. Watch the Debian tracker page for this CVE. Advisories for trixie have historically landed a median of 11 days after publication.
Debian 14forky	fixed	6.19.12-1	Update the kernel and reboot. Fixed in 6.19.12-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	6.19.12-1	Update the kernel and reboot. Fixed in 6.19.12-1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

syzbot reported a soft lockup in mptcp_recvmsg() [0]. When receiving data with MSG_PEEK | MSG_WAITALL flags, the skb is not removed from the sk_receive_queue. This causes sk_wait_data() to always find available data and never perform actual waiting, leading to a soft lockup. Fix this by adding a 'last' parameter to track the last peeked skb. This allows sk_wait_data() to make informed waiting decisions and prevent infinite loops when MSG_PEEK is used. [0]: watchdog: BUG: soft lockup - CPU#2 stuck for 156s! [server:1963] Modules linked in: CPU: 2 UID: 0 PID: 1963 Comm: server Not tainted 6.19.0-rc8 #61 PREEMPT(none) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:sk_wait_data+0x15/0x190 Code: 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 41 56 41 55 41 54 49 89 f4 55 48 89 d5 53 48 89 fb <48> 83 ec 30 65 48 8b 05 17 a4 6b 01 48 89 44 24 28 31 c0 65 48 8b RSP: 0018:ffffc90000603ca0 EFLAGS: 00000246 RAX: 0000000000000000 RBX: ffff888102bf0800 RCX: 0000000000000001 RDX: 0000000000000000 RSI: ffffc90000603d18 RDI: ffff888102bf0800 RBP: 0000000000000000 R08: 0000000000000002 R09: 0000000000000101 R10: 0000000000000000 R11: 0000000000000075 R12: ffffc90000603d18 R13: ffff888102bf0800 R14: ffff888102bf0800 R15: 0000000000000000 FS: 00007f6e38b8c4c0(0000) GS:ffff8881b877e000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055aa7bff1680 CR3: 0000000105cbe000 CR4: 00000000000006f0 Call Trace: <TASK> mptcp_recvmsg+0x547/0x8c0 net/mptcp/protocol.c:2329 inet_recvmsg+0x11f/0x130 net/ipv4/af_inet.c:891 sock_recvmsg+0x94/0xc0 net/socket.c:1100 __sys_recvfrom+0xb2/0x130 net/socket.c:2256 __x64_sys_recvfrom+0x1f/0x30 net/socket.c:2267 do_syscall_64+0x59/0x2d0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e arch/x86/entry/entry_64.S:131 RIP: 0033:0x7f6e386a4a1d Code: 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8d 05 f1 de 2c 00 41 89 ca 8b 00 85 c0 75 20 45 31 c9 45 31 c0 b8 2d 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 6b f3 c3 66 0f 1f 84 00 00 00 00 00 41 56 41 RSP: 002b:00007ffc3c4bb078 EFLAGS: 00000246 ORIG_RAX: 000000000000002d RAX: ffffffffffffffda RBX: 000000000000861e RCX: 00007f6e386a4a1d RDX: 00000000000003ff RSI: 00007ffc3c4bb150 RDI: 0000000000000004 RBP: 00007ffc3c4bb570 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000103 R11: 0000000000000246 R12: 00005605dbc00be0 R13: 00007ffc3c4bb650 R14: 0000000000000000 R15: 0000000000000000 </TASK>

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

net/mptcp/protocol.c

What this is: NETWORKING [MPTCP]MAINTAINERS section matched on net/mptcp/ · netdev@vger.kernel.org · Maintained

Check it on the machine

grep -w CONFIG_MPTCP /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

Show whether Debian builds this, per release

Debian builds this code. Every release below compiles the affected file into the kernels it ships.

bookworm, trixie, forky, sidy

y: built into the kernel image on every flavour - only a patch removes it

Build switch: CONFIG_MPTCP

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Debian tracker CVE record NVD kernel CNA record

Signals

Published: 2026-05-01 (6 months ago)source
CVSS: 7.5 high
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:Hsource recompute it
Attack vector: network (AV:N)source
EPSS: 0.47%, higher than 39.3% of all CVEssource
CISA KEV: not listedthe KEV catalogue
Debian urgency: unimportantsource
Subsystem: net/mptcp

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
6.18	6.18.22	58b58b9ba89c
6.18	6.19.12	de3c248d1b69
6.18	7.0	5dd8025a49c2
6.6.117	0	0
6.12.59	0	0
6.17.8	0	0

Why the CNA scored it this way

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:NAttack vector, network: MPTCP is a TCP-based network protocol, and in a reasonable network-facing MPTCP service using recv with MSG_PEEK|MSG_WAITALL, a remote peer can populate the receive queue and trigger the vulnerable receive path by sending insufficient data. The vulnerable function is reached through normal socket receive handling for MPTCP data.
AC:LAttack complexity, low: No race, memory layout, or hard-to-control timing is required; once the target performs the blocking peek receive, the attacker controls whether the receive queue contains the same partial data that causes the loop. The condition is reliably repeatable.
PR:NPrivileges required, none: A remote peer does not need local credentials or kernel capabilities to connect to an exposed MPTCP service and send data before authentication. MPTCP socket creation itself has no capability gate and is enabled by default when configured.
UI:NUser interaction, none: No human user action is required after the vulnerable service is running. The trigger is normal network traffic plus the service's receive call.
S:UScope, unchanged: The impact is a kernel availability failure on the same host/security authority. It does not cross a VM, IOMMU, or sandbox boundary.
C:NConfidentiality impact, none: The bug is an infinite receive/wait loop caused by MSG_PEEK retaining the skb on the receive queue. There is no memory corruption or information disclosure primitive.
I:NIntegrity impact, none: The fix and code path show no unauthorized write, data modification, or control-flow corruption. The observed failure is a soft lockup only.
A:HAvailability impact, high: The bug causes sk_wait_data to return immediately forever, producing a kernel soft lockup with a CPU stuck for an extended period. Repeated connections could consume availability, so the availability impact is high.