CVE-2025-38453

What it actually does

Use-after-free in io_uring msg_ring request handling where a freed io_kiocb is accessed during deferred local task_work addition, allowing memory corruption after RCU grace period violation.

Why it matters to the business

Linux systems relying on io_uring for high-performance I/O face elevated risk of kernel crashes, potential privilege escalation, or service disruption; low EPSS and no KEV listing reduce immediate widespread threat but slight score increase over 30 days warrants monitoring.

How an attack unfolds

An attacker triggers msg_ring operations across rings to allocate and free requests independently, then posts data that schedules task_work on an already-freed request via io_req_local_work_add, leading to KASAN-detected access of invalid memory; listed threat actors have not been tied to this specific flaw.

How to fix it

Update the Linux kernel to a version containing the RCU deferral fix using kfree_rcu for io_kiocb objects in io_msg_tw_complete and related paths; for listed Debian packages apply the referenced webkit2gtk 2.48.0-1 or 2.48.0-1~deb12u1 updates where applicable.

How to confirm the fix worked

Rebuild with KASAN enabled and re-run the syzbot reproducer or equivalent io_uring msg_ring workloads; confirm absence of kasan_report in io_req_local_work_add and verify kfree_rcu usage in msg_ring.c.

Typical attack path

1. Craft io_uring submission queue entries that invoke msg_ring with remote posting
2. Force independent allocation and freeing of msg_ring requests outside normal request lifecycle
3. Trigger io_msg_remote_post and __io_req_task_work_add on the now-freed io_kiocb
4. Observe or exploit resulting use-after-free during io_wq_worker handling

How to detect it

Search kernel logs and audit trails for KASAN reports referencing io_req_local_work_add or __io_msg_ring_data; inspect io_uring worker process activity and task_work scheduling events around msg_ring calls; no confirmed threat actor campaigns are associated with this CVE.

What your security team should do

• Prioritize kernel upgrades on systems with heavy io_uring usage within standard patch cycles given absence of KEV status
• Monitor EPSS trend for continued upward movement and reassess if exploit maturity changes
• Audit custom io_uring applications for msg_ring usage patterns that could surface the deferred-free condition