GHSA-4XC2-JWRR-PXH9
Vulnerability from github – Published: 2025-10-01 12:30 – Updated: 2026-01-16 21:30In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix disconnect vs accept race
Despite commit 0ad529d9fd2b ("mptcp: fix possible divide by zero in recvmsg()"), the mptcp protocol is still prone to a race between disconnect() (or shutdown) and accept.
The root cause is that the mentioned commit checks the msk-level flag, but mptcp_stream_accept() does acquire the msk-level lock, as it can rely directly on the first subflow lock.
As reported by Christoph than can lead to a race where an msk socket is accepted after that mptcp_subflow_queue_clean() releases the listener socket lock and just before it takes destructive actions leading to the following splat:
BUG: kernel NULL pointer dereference, address: 0000000000000012 PGD 5a4ca067 P4D 5a4ca067 PUD 37d4c067 PMD 0 Oops: 0000 [#1] PREEMPT SMP CPU: 2 PID: 10955 Comm: syz-executor.5 Not tainted 6.5.0-rc1-gdc7b257ee5dd #37 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 RIP: 0010:mptcp_stream_accept+0x1ee/0x2f0 include/net/inet_sock.h:330 Code: 0a 09 00 48 8b 1b 4c 39 e3 74 07 e8 bc 7c 7f fe eb a1 e8 b5 7c 7f fe 4c 8b 6c 24 08 eb 05 e8 a9 7c 7f fe 49 8b 85 d8 09 00 00 <0f> b6 40 12 88 44 24 07 0f b6 6c 24 07 bf 07 00 00 00 89 ee e8 89 RSP: 0018:ffffc90000d07dc0 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff888037e8d020 RCX: ffff88803b093300 RDX: 0000000000000000 RSI: ffffffff833822c5 RDI: ffffffff8333896a RBP: 0000607f82031520 R08: ffff88803b093300 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000003e83 R12: ffff888037e8d020 R13: ffff888037e8c680 R14: ffff888009af7900 R15: ffff888009af6880 FS: 00007fc26d708640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000012 CR3: 0000000066bc5001 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: do_accept+0x1ae/0x260 net/socket.c:1872 __sys_accept4+0x9b/0x110 net/socket.c:1913 __do_sys_accept4 net/socket.c:1954 [inline] __se_sys_accept4 net/socket.c:1951 [inline] __x64_sys_accept4+0x20/0x30 net/socket.c:1951 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x47/0xa0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Address the issue by temporary removing the pending request socket from the accept queue, so that racing accept() can't touch them.
After depleting the msk - the ssk still exists, as plain TCP sockets, re-insert them into the accept queue, so that later inet_csk_listen_stop() will complete the tcp socket disposal.
{
"affected": [],
"aliases": [
"CVE-2023-53490"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-01T12:15:52Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix disconnect vs accept race\n\nDespite commit 0ad529d9fd2b (\"mptcp: fix possible divide by zero in\nrecvmsg()\"), the mptcp protocol is still prone to a race between\ndisconnect() (or shutdown) and accept.\n\nThe root cause is that the mentioned commit checks the msk-level\nflag, but mptcp_stream_accept() does acquire the msk-level lock,\nas it can rely directly on the first subflow lock.\n\nAs reported by Christoph than can lead to a race where an msk\nsocket is accepted after that mptcp_subflow_queue_clean() releases\nthe listener socket lock and just before it takes destructive\nactions leading to the following splat:\n\nBUG: kernel NULL pointer dereference, address: 0000000000000012\nPGD 5a4ca067 P4D 5a4ca067 PUD 37d4c067 PMD 0\nOops: 0000 [#1] PREEMPT SMP\nCPU: 2 PID: 10955 Comm: syz-executor.5 Not tainted 6.5.0-rc1-gdc7b257ee5dd #37\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014\nRIP: 0010:mptcp_stream_accept+0x1ee/0x2f0 include/net/inet_sock.h:330\nCode: 0a 09 00 48 8b 1b 4c 39 e3 74 07 e8 bc 7c 7f fe eb a1 e8 b5 7c 7f fe 4c 8b 6c 24 08 eb 05 e8 a9 7c 7f fe 49 8b 85 d8 09 00 00 \u003c0f\u003e b6 40 12 88 44 24 07 0f b6 6c 24 07 bf 07 00 00 00 89 ee e8 89\nRSP: 0018:ffffc90000d07dc0 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: ffff888037e8d020 RCX: ffff88803b093300\nRDX: 0000000000000000 RSI: ffffffff833822c5 RDI: ffffffff8333896a\nRBP: 0000607f82031520 R08: ffff88803b093300 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000003e83 R12: ffff888037e8d020\nR13: ffff888037e8c680 R14: ffff888009af7900 R15: ffff888009af6880\nFS: 00007fc26d708640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000012 CR3: 0000000066bc5001 CR4: 0000000000370ee0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u003cTASK\u003e\n do_accept+0x1ae/0x260 net/socket.c:1872\n __sys_accept4+0x9b/0x110 net/socket.c:1913\n __do_sys_accept4 net/socket.c:1954 [inline]\n __se_sys_accept4 net/socket.c:1951 [inline]\n __x64_sys_accept4+0x20/0x30 net/socket.c:1951\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x47/0xa0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n\nAddress the issue by temporary removing the pending request socket\nfrom the accept queue, so that racing accept() can\u0027t touch them.\n\nAfter depleting the msk - the ssk still exists, as plain TCP sockets,\nre-insert them into the accept queue, so that later inet_csk_listen_stop()\nwill complete the tcp socket disposal.",
"id": "GHSA-4xc2-jwrr-pxh9",
"modified": "2026-01-16T21:30:30Z",
"published": "2025-10-01T12:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53490"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/511b90e39250135a7f900f1c3afbce25543018a2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b2b4c84eb7149f34c0f25f17042d095ba5357d68"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ded9f5551ce5cafa3c41c794428c27a0d0a00542"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.