CVE-2025-71126

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: avoid deadlock on fallback while reinjecting<br /> <br /> Jakub reported an MPTCP deadlock at fallback time:<br /> <br /> WARNING: possible recursive locking detected<br /> 6.18.0-rc7-virtme #1 Not tainted<br /> --------------------------------------------<br /> mptcp_connect/20858 is trying to acquire lock:<br /> ff1100001da18b60 (&amp;msk-&gt;fallback_lock){+.-.}-{3:3}, at: __mptcp_try_fallback+0xd8/0x280<br /> <br /> but task is already holding lock:<br /> ff1100001da18b60 (&amp;msk-&gt;fallback_lock){+.-.}-{3:3}, at: __mptcp_retrans+0x352/0xaa0<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> <br /> CPU0<br /> ----<br /> lock(&amp;msk-&gt;fallback_lock);<br /> lock(&amp;msk-&gt;fallback_lock);<br /> <br /> *** DEADLOCK ***<br /> <br /> May be due to missing lock nesting notation<br /> <br /> 3 locks held by mptcp_connect/20858:<br /> #0: ff1100001da18290 (sk_lock-AF_INET){+.+.}-{0:0}, at: mptcp_sendmsg+0x114/0x1bc0<br /> #1: ff1100001db40fd0 (k-sk_lock-AF_INET#2){+.+.}-{0:0}, at: __mptcp_retrans+0x2cb/0xaa0<br /> #2: ff1100001da18b60 (&amp;msk-&gt;fallback_lock){+.-.}-{3:3}, at: __mptcp_retrans+0x352/0xaa0<br /> <br /> stack backtrace:<br /> CPU: 0 UID: 0 PID: 20858 Comm: mptcp_connect Not tainted 6.18.0-rc7-virtme #1 PREEMPT(full)<br /> Hardware name: Bochs, BIOS Bochs 01/01/2011<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x6f/0xa0<br /> print_deadlock_bug.cold+0xc0/0xcd<br /> validate_chain+0x2ff/0x5f0<br /> __lock_acquire+0x34c/0x740<br /> lock_acquire.part.0+0xbc/0x260<br /> _raw_spin_lock_bh+0x38/0x50<br /> __mptcp_try_fallback+0xd8/0x280<br /> mptcp_sendmsg_frag+0x16c2/0x3050<br /> __mptcp_retrans+0x421/0xaa0<br /> mptcp_release_cb+0x5aa/0xa70<br /> release_sock+0xab/0x1d0<br /> mptcp_sendmsg+0xd5b/0x1bc0<br /> sock_write_iter+0x281/0x4d0<br /> new_sync_write+0x3c5/0x6f0<br /> vfs_write+0x65e/0xbb0<br /> ksys_write+0x17e/0x200<br /> do_syscall_64+0xbb/0xfd0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x7fa5627cbc5e<br /> Code: 4d 89 d8 e8 14 bd 00 00 4c 8b 5d f8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 11 c9 c3 0f 1f 80 00 00 00 00 48 8b 45 10 0f 05 c3 83 e2 39 83 fa 08 75 e7 e8 13 ff ff ff 0f 1f 00 f3 0f 1e fa<br /> RSP: 002b:00007fff1fe14700 EFLAGS: 00000202 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fa5627cbc5e<br /> RDX: 0000000000001f9c RSI: 00007fff1fe16984 RDI: 0000000000000005<br /> RBP: 00007fff1fe14710 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000202 R12: 00007fff1fe16920<br /> R13: 0000000000002000 R14: 0000000000001f9c R15: 0000000000001f9c<br /> <br /> The packet scheduler could attempt a reinjection after receiving an<br /> MP_FAIL and before the infinite map has been transmitted, causing a<br /> deadlock since MPTCP needs to do the reinjection atomically from WRT<br /> fallback.<br /> <br /> Address the issue explicitly avoiding the reinjection in the critical<br /> scenario. Note that this is the only fallback critical section that<br /> could potentially send packets and hit the double-lock.