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:
iouring/msgring: ensure iokiocb freeing is deferred for RCU
syzbot reports that defer/local taskwork adding via msgring 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> dumpstacklvl+0x189/0x250 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:408 [inline] printreport+0xd2/0x2b0 mm/kasan/report.c:521 kasanreport+0x118/0x150 mm/kasan/report.c:634 ioreqlocalworkadd iouring/iouring.c:1184 [inline] ioreqtaskworkadd+0x589/0x950 iouring/iouring.c:1252 iomsgremotepost iouring/msgring.c:103 [inline] iomsgdataremote iouring/msgring.c:133 [inline] iomsgringdata+0x820/0xaa0 iouring/msgring.c:151 iomsgringdata iouring/msgring.c:173 [inline] iomsgring+0x134/0xa00 iouring/msgring.c:314 ioissuesqe+0x17e/0x4b0 iouring/iouring.c:1739 ioissuesqe+0x165/0xfd0 iouring/iouring.c:1762 iowqsubmitwork+0x6e9/0xb90 iouring/iouring.c:1874 ioworkerhandlework+0x7cd/0x1180 iouring/io-wq.c:642 iowqworker+0x42f/0xeb0 iouring/io-wq.c:696 retfromfork+0x3fc/0x770 arch/x86/kernel/process.c:148 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.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 rcuhead and use kfreercu() in both spots where requests are freed. Only the one in iomsgtwcomplete() 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Modify the io_uring request freeing logic to add an rcu_head to the request structure and use kfree_rcu() when freeing io_kiocb in both spots: (1) the required path in io_msg_tw_complete(), and (2) the corresponding free in the other ring/request completion spot (the same request that is freed in the local/remote msg_ring flow). The goal is to defer freeing so KASAN doesn't observe a freed request being visible/used by another ring.
Linux kernel io_uring/msg_ring (io_msg_tw_complete / io_msg_ring remote path) RCU-based deferred freeing for request (io_kiocb) = Use rcu_head and kfree_rcu() consistently
Event History
Frequently Asked Questions
What is the severity of CVE-2025-38453?
CVE-2025-38453 is classified as a moderate severity vulnerability affecting the Linux kernel.
How do I fix CVE-2025-38453?
To mitigate CVE-2025-38453, update your Linux kernel to version 6.16.0 or later.
What kind of systems are affected by CVE-2025-38453?
CVE-2025-38453 affects Linux kernel versions starting from 6.16.0-rc4.
What components are involved in CVE-2025-38453?
CVE-2025-38453 involves io_uring and msg_ring components within the Linux kernel.
Is CVE-2025-38453 exploited in the wild?
As of now, there is no public information confirming the exploitation of CVE-2025-38453 in the wild.