CVE-2025-38453: io_uring/msg_ring: ensure io_kiocb freeing is deferred for RCU
In the Linux kernel, the following vulnerability has been resolved:
io_uring/msg_ring: ensure io_kiocb freeing is deferred for RCU
syzbot reports that defer/local task_work adding via msg_ring can hit
a request that has been freed:
CPU: 1 UID: 0 PID: 19356 Comm: iou-wrk-19354 Not tainted 6.16.0-rc4-syzkaller-00108-g17bbde2e1716 #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
Call Trace:
<TASK>
dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:408 [inline]
print_report+0xd2/0x2b0 mm/kasan/report.c:521
kasan_report+0x118/0x150 mm/kasan/report.c:634
io_req_local_work_add io_uring/io_uring.c:1184 [inline]
__io_req_task_work_add+0x589/0x950 io_uring/io_uring.c:1252
io_msg_remote_post io_uring/msg_ring.c:103 [inline]
io_msg_data_remote io_uring/msg_ring.c:133 [inline]
__io_msg_ring_data+0x820/0xaa0 io_uring/msg_ring.c:151
io_msg_ring_data io_uring/msg_ring.c:173 [inline]
io_msg_ring+0x134/0xa00 io_uring/msg_ring.c:314
__io_issue_sqe+0x17e/0x4b0 io_uring/io_uring.c:1739
io_issue_sqe+0x165/0xfd0 io_uring/io_uring.c:1762
io_wq_submit_work+0x6e9/0xb90 io_uring/io_uring.c:1874
io_worker_handle_work+0x7cd/0x1180 io_uring/io-wq.c:642
io_wq_worker+0x42f/0xeb0 io_uring/io-wq.c:696
ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
which is supposed to be safe with how requests are allocated. But msg
ring requests alloc and free on their own, and hence must defer freeing
to a sane time.
Add an rcu_head and use kfree_rcu() in both spots where requests are
freed. Only the one in io_msg_tw_complete() is strictly required as it
has been visible on the other ring, but use it consistently in the other
spot as well.
This should not cause any other issues outside of KASAN rightfully
complaining about it.
Security readout for executives and security teams
Plain-English summary
A Linux io_uring memory-lifetime flaw can let a locally authenticated, low-privilege user trigger access to an already-freed request. The supplied CVSS assessment indicates possible compromise of confidentiality, integrity, and availability, although the source describes the observed failure through KASAN rather than a demonstrated real-world attack.
Executive priority
Treat as a high-priority kernel maintenance issue, especially on shared or multi-user Linux systems. It is not supported as an emergency internet-wide threat because exploitation requires local privileges and no active exploitation is documented. Obtain vendor package guidance promptly and schedule the corrected kernel according to local exposure.
Technical view
msg_ring requests can be freed while another ring still references them through deferred or local task work, creating a use-after-free condition. The kernel fix adds an rcu_head and uses kfree_rcu() at both request-freeing locations so reclamation occurs only after RCU readers are safe.
Likely exposure
Exposure is limited to Linux systems running the listed affected releases, including 6.11, 6.12.46, 6.15.7, and 6.16, where a low-privilege local account can reach the vulnerable io_uring msg_ring path. The supplied version data is unusual and insufficient for precise distribution-package mapping.
Exploitation context
The CVSS vector describes local, low-complexity exploitation requiring low privileges and no user interaction. The supplied record is not in KEV and provides no evidence of active exploitation, public weaponization, or remote reachability. Discovery came from syzbot with KASAN detecting the invalid memory access.
Researcher notes
The report identifies a request-lifetime race involving remote msg_ring posting and task-work addition. RCU-deferred freeing addresses visibility across rings. The source notes that only io_msg_tw_complete() strictly required the change, with the second free site updated for consistency. No exploitability demonstration or affected architecture constraints are supplied.
Mitigation direction
Install a vendor-supported kernel containing the referenced upstream fix or its distribution backport.
Check Linux distribution advisories for exact affected and corrected package versions.
Prioritize multi-user systems where untrusted local accounts can access io_uring.
Use vendor-recommended temporary restrictions if an immediate kernel update is unavailable.
Validation and detection
Record each host's running kernel release and distribution package version.
Map distribution packages to the three referenced stable-kernel fix commits.
Confirm the corrected kernel is installed and active after reboot.
Review whether untrusted local users can access the affected io_uring functionality.
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.
cve · low confidence lookup
CVE-2025-38453 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
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.
1CVSS vectors
3Timeline events
0ADP providers
4Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.