CVE-2025-21875: mptcp: always handle address removal under msk socket lock
In the Linux kernel, the following vulnerability has been resolved:
mptcp: always handle address removal under msk socket lock
Syzkaller reported a lockdep splat in the PM control path:
WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 sockownedbyme include/net/sock.h:1711 [inline] WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 mskownedbyme net/mptcp/protocol.h:363 [inline] WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 mptcppmnladdrsendack+0x57c/0x610 net/mptcp/pmnetlink.c:788 Modules linked in: CPU: 0 UID: 0 PID: 6693 Comm: syz.0.205 Not tainted 6.14.0-rc2-syzkaller-00303-gad1b832bf1cf #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024 RIP: 0010:sockownedbyme include/net/sock.h:1711 [inline] RIP: 0010:mskownedbyme net/mptcp/protocol.h:363 [inline] RIP: 0010:mptcppmnladdrsendack+0x57c/0x610 net/mptcp/pmnetlink.c:788 Code: 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ca 7b d3 f5 eb b9 e8 c3 7b d3 f5 90 0f 0b 90 e9 dd fb ff ff e8 b5 7b d3 f5 90 <0f> 0b 90 e9 3e fb ff ff 44 89 f1 80 e1 07 38 c1 0f 8c eb fb ff ff RSP: 0000:ffffc900034f6f60 EFLAGS: 00010283 RAX: ffffffff8bee3c2b RBX: 0000000000000001 RCX: 0000000000080000 RDX: ffffc90004d42000 RSI: 000000000000a407 RDI: 000000000000a408 RBP: ffffc900034f7030 R08: ffffffff8bee37f6 R09: 0100000000000000 R10: dffffc0000000000 R11: ffffed100bcc62e4 R12: ffff88805e6316e0 R13: ffff88805e630c00 R14: dffffc0000000000 R15: ffff88805e630c00 FS: 00007f7e9a7e96c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2fd18ff8 CR3: 0000000032c24000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> mptcppmremoveaddr+0x103/0x1d0 net/mptcp/pm.c:59 mptcppmremoveannoaddr+0x1f4/0x2f0 net/mptcp/pmnetlink.c:1486 mptcpnlremovesubflowandsignaladdr net/mptcp/pmnetlink.c:1518 [inline] mptcppmnldeladdrdoit+0x118d/0x1af0 net/mptcp/pmnetlink.c:1629 genlfamilyrcvmsgdoit net/netlink/genetlink.c:1115 [inline] genlfamilyrcvmsg net/netlink/genetlink.c:1195 [inline] genlrcvmsg+0xb1f/0xec0 net/netlink/genetlink.c:1210 netlinkrcvskb+0x206/0x480 net/netlink/afnetlink.c:2543 genlrcv+0x28/0x40 net/netlink/genetlink.c:1219 netlinkunicastkernel net/netlink/afnetlink.c:1322 [inline] netlinkunicast+0x7f6/0x990 net/netlink/afnetlink.c:1348 netlinksendmsg+0x8de/0xcb0 net/netlink/afnetlink.c:1892 socksendmsgnosec net/socket.c:718 [inline] socksendmsg+0x221/0x270 net/socket.c:733 syssendmsg+0x53a/0x860 net/socket.c:2573 syssendmsg net/socket.c:2627 [inline] syssendmsg+0x269/0x350 net/socket.c:2659 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f7e9998cde9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f7e9a7e9038 EFLAGS: 00000246 ORIGRAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f7e99ba5fa0 RCX: 00007f7e9998cde9 RDX: 000000002000c094 RSI: 0000400000000000 RDI: 0000000000000007 RBP: 00007f7e99a0e2a0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f7e99ba5fa0 R15: 00007fff49231088
Indeed the PM can try to send a RMADDR over a msk without acquiring first the msk socket lock.
The bugged code-path comes from an early optimization: when there are no subflows, the PM should (usually) not send RMADDR notifications.
The above statement is incorrect, as without locks another process could concur ---truncated---
Affected Software
Event History
Frequently Asked Questions
What access does an attacker need to exploit this issue?
The supplied CVSS vector indicates local access, low attack complexity, low privileges, and no user interaction are required. It also indicates potential impact to confidentiality, integrity, and availability.
Which kernel functionality is involved?
The issue is in the Linux kernel's Multipath TCP (MPTCP) path-management control path, specifically address removal handling and socket locking.
How was the problem observed?
Syzkaller reported a lockdep warning in the MPTCP path-manager control path, with the warning occurring in mptcp_pm_nl_addr_send_ack while checking ownership of the MPTCP socket lock.
Are fixes available?
The provided references include three Linux stable kernel commits associated with the resolution. Consult those referenced stable commits to determine whether they are present in the kernel source or vendor kernel package in use.