CVE-2024-50079

What it actually does

io_uring sqpoll thread may invoke task_work while still in TASK_INTERRUPTIBLE state, allowing blocking operations such as mutex_lock on the ring mutex to be attempted without TASK_RUNNING, triggering scheduler warnings and potential incorrect scheduling behavior.

Why it matters to the business

Kernel-level instability or warnings during io_uring shutdown on affected Linux systems can lead to degraded I/O performance or unexpected process behavior in applications relying on asynchronous I/O, increasing operational overhead for environments with high io_uring usage.

How an attack unfolds

An attacker would need to trigger sqpoll exit conditions while pending task_work items exist and the thread is waiting on the io_uring_task waitqueue; the flaw itself produces a diagnostic splat rather than direct code execution, though similar kernel state issues have been abused by espionage and financially motivated actors in broader Linux kernel campaigns.

How to fix it

Upgrade affected Linux kernel packages to versions containing the fix that ensures TASK_RUNNING state before running task_work in the sqpoll exit path; apply the referenced stable backports for the 6.12-rc series and subsequent releases.

How to confirm the fix worked

Confirm the kernel version includes the commit ensuring task state is TASK_RUNNING in io_uring_cancel_generic and io_sq_thread paths; monitor for absence of __might_sleep warnings referencing io_handle_tw_list or mutex_lock during io_uring shutdown.

Typical attack path

1. Cause sqpoll thread to begin exit path
2. Ensure pending task_work items exist that require running from io_uring_cancel_generic
3. Enter wait on io_uring_task waitqueue leaving state as TASK_INTERRUPTIBLE
4. Trigger io_run_task_work which calls blocking operations without resetting state
5. Observe scheduler warning or potential follow-on scheduling anomalies

How to detect it

Search kernel logs and dmesg for __might_sleep warnings mentioning prepare_to_wait, mutex_lock, io_handle_tw_list, or io_uring_cancel_generic on CPUs running iou-sqp threads; correlate with process names containing iou-sqp.

What your security team should do

• Prioritize kernel updates on systems using io_uring with sqpoll enabled
• Review application usage of io_uring for potential exposure during high-load shutdown scenarios
• Monitor kernel logs for scheduler warnings involving io_uring task work
• Test io_uring workloads after patching to verify no state-related splats occur