CVE-2024-56584

What it actually does

Local memory allocation failure during xa_store() in io_uring task context tracking can leave an xarray with non-NULL head but no entries, triggering WARN_ON_ONCE in __io_uring_free() on final put and causing kernel warning or availability impact.

Why it matters to the business

Local users on affected Linux kernels may trigger kernel warnings or system instability during I/O operations, increasing operational risk on servers and endpoints using io_uring; low exploit likelihood reduces immediate urgency but still requires patching.

How an attack unfolds

An attacker with local low-privileged access runs a program that creates io_uring instances while inducing memory allocation failures; this exercises the xa_store() path, leaves the xarray inconsistent, and hits the sanity check on task exit, surfacing the warning.

How to fix it

Update the Linux kernel to a version containing commit 94ad56f61b873ffeebcc620d451eacfbdf9d40f0 or later; rebuild and reboot into the fixed kernel; disable io_uring via kernel command line if immediate mitigation is required on unpatchable systems.

How to confirm the fix worked

Confirm kernel version includes the referenced commit; run syzbot-style reproducers that inject allocation failures and verify absence of the tctx.c:51 WARN_ON; inspect /proc/config.gz or kernel source for the workaround code.

Typical attack path

1. Obtain local shell or process execution on target Linux system
2. Create io_uring ring and submit operations under memory pressure
3. Force allocation failures in xa_store() within tctx
4. Trigger final put of io_uring_task to reach __io_uring_free()
5. Observe WARN_ON or resulting availability impact

How to detect it

Search kernel logs (dmesg, syslog, journalctl) for the exact WARN_ON string referencing io_uring/tctx.c:51 and __io_uring_free; correlate with process creation of io_uring-using binaries under memory pressure; review audit logs for unusual local process activity around io_uring syscalls.

• WARNING: CPU: .* PID: .* at io_uring/tctx.c:51 __io_uring_free
• WARN_ON_ONCE(!xa_empty(&tctx->xa))

What your security team should do

• Prioritize kernel upgrade on all systems exposing io_uring to untrusted local users
• Monitor for the specific WARN_ON string in dmesg and kernel logs
• Review application use of io_uring and apply least-privilege where possible
• Test fixed kernels in staging before broad rollout