CVE-2025-38453

In the Linux kernel, the following vulnerability has been resolved:

iouring/msgring: ensure io_kiocb 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 iomsgtw_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.