CVE-2023-53072: mptcp: use the workqueue to destroy unaccepted sockets
In the Linux kernel, the following vulnerability has been resolved:
mptcp: use the workqueue to destroy unaccepted sockets
Christoph reported a UaF at token lookup time after having
refactored the passive socket initialization part:
BUG: KASAN: use-after-free in __token_bucket_busy+0x253/0x260
Read of size 4 at addr ffff88810698d5b0 by task syz-executor653/3198
CPU: 1 PID: 3198 Comm: syz-executor653 Not tainted 6.2.0-rc59af4eaa31c1f6c00c8f1e448ed99a45c66340dd5 #6
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x6e/0x91
print_report+0x16a/0x46f
kasan_report+0xad/0x130
__token_bucket_busy+0x253/0x260
mptcp_token_new_connect+0x13d/0x490
mptcp_connect+0x4ed/0x860
__inet_stream_connect+0x80e/0xd90
tcp_sendmsg_fastopen+0x3ce/0x710
mptcp_sendmsg+0xff1/0x1a20
inet_sendmsg+0x11d/0x140
__sys_sendto+0x405/0x490
__x64_sys_sendto+0xdc/0x1b0
do_syscall_64+0x3b/0x90
entry_SYSCALL_64_after_hwframe+0x72/0xdc
We need to properly clean-up all the paired MPTCP-level
resources and be sure to release the msk last, even when
the unaccepted subflow is destroyed by the TCP internals
via inet_child_forget().
We can re-use the existing MPTCP_WORK_CLOSE_SUBFLOW infra,
explicitly checking that for the critical scenario: the
closed subflow is the MPC one, the msk is not accepted and
eventually going through full cleanup.
With such change, __mptcp_destroy_sock() is always called
on msk sockets, even on accepted ones. We don't need anymore
to transiently drop one sk reference at msk clone time.
Please note this commit depends on the parent one:
mptcp: refactor passive socket initialization
Security readout for executives and security teams
Plain-English summary
CVE-2023-53072 is a Linux kernel MPTCP cleanup bug that can leave a socket object used after it was freed. The public record shows it was found through KASAN during testing and fixed in stable kernel commits. No active exploitation is cited in the provided sources.
Executive priority
Treat as a kernel maintenance priority, not an emergency based on current evidence. Patch through normal urgent kernel update cycles, especially on exposed or shared infrastructure, because use-after-free bugs can have serious consequences even when public exploit evidence is absent.
Technical view
The flaw is a use-after-free in MPTCP token lookup after passive socket initialization changes. The fix moves destruction of unaccepted sockets through MPTCP workqueue cleanup so paired MPTCP resources are released in order and the MPTCP socket is released last.
Likely exposure
Exposure is limited to Linux systems running affected kernel versions with MPTCP code present and relevant socket paths reachable. The provided data names Linux kernel versions around 5.7 through stable fixes, but does not provide distribution package mappings.
Exploitation context
The bundle shows a KASAN crash from a syzkaller-style executor path. It does not cite public exploitation, KEV listing, exploit availability, privilege requirements, or a confirmed real-world attack path.
Researcher notes
Key unknowns are practical exploitability, required local or remote reachability, and distro-specific affected ranges. The strongest evidence is the kernel commit narrative and KASAN trace; there is no CVSS, CWE, KEV, or exploit confirmation in the provided bundle.
Mitigation direction
Update to a Linux kernel containing the referenced stable fixes.
Use distribution security advisories to map fixed package versions.
Prioritize internet-facing or multi-tenant systems where MPTCP is enabled or used.
Check vendor guidance before applying non-patch mitigations.
Avoid direct deployment shortcuts; follow normal kernel change controls.
Validation and detection
Inventory Linux kernel versions across servers, appliances, and container hosts.
Check whether deployed kernels include the referenced stable commits.
Confirm distribution advisories map CVE-2023-53072 to installed packages.
Review MPTCP usage or configuration where operationally relevant.
Run regression tests for networking workloads after kernel updates.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
description · low confidence lookup
Credential and access behavior lookup
The CVE wording references authentication or credential exposure, so valid-account and credential-access review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
4Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
May 2, 2025, 15:55 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.