CVE-2024-40922 in Linux
Summary
by MITRE • 07/12/2024
In the Linux kernel, the following vulnerability has been resolved:
io_uring/rsrc: don't lock while !TASK_RUNNING
There is a report of io_rsrc_ref_quiesce() locking a mutex while not TASK_RUNNING, which is due to forgetting restoring the state back after io_run_task_work_sig() and attempts to break out of the waiting loop.
do not call blocking ops when !TASK_RUNNING; state=1 set at [] prepare_to_wait+0xa4/0x380
kernel/sched/wait.c:237 WARNING: CPU: 2 PID: 397056 at kernel/sched/core.c:10099 __might_sleep+0x114/0x160 kernel/sched/core.c:10099 RIP: 0010:__might_sleep+0x114/0x160 kernel/sched/core.c:10099 Call Trace: __mutex_lock_common kernel/locking/mutex.c:585 [inline]
__mutex_lock+0xb4/0x940 kernel/locking/mutex.c:752 io_rsrc_ref_quiesce+0x590/0x940 io_uring/rsrc.c:253 io_sqe_buffers_unregister+0xa2/0x340 io_uring/rsrc.c:799 __io_uring_register io_uring/register.c:424 [inline]
__do_sys_io_uring_register+0x5b9/0x2400 io_uring/register.c:613 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xd8/0x270 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x6f/0x77
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/03/2025
The vulnerability identified as CVE-2024-40922 resides within the Linux kernel's io_uring subsystem, specifically in the resource management functionality. This issue manifests when the io_rsrc_ref_quiesce() function attempts to acquire a mutex lock while the task is not in TASK_RUNNING state, creating a potential deadlock scenario that could compromise system stability. The root cause stems from improper state management during the execution flow, where the task state is not correctly restored after io_run_task_work_sig() completes its operations, leading to a situation where blocking operations are attempted on a non-running task.
The technical flaw occurs in the io_uring resource management code where the kernel scheduler's locking mechanisms detect an inappropriate blocking operation when a task is not in the proper running state. The error trace indicates that the system attempts to call __mutex_lock() while the task state is set to 1, which corresponds to TASK_INTERRUPTIBLE or similar non-running states according to the kernel's task state definitions. This violates fundamental kernel design principles that prevent blocking operations on tasks that are not in TASK_RUNNING state, as documented in the Linux kernel's scheduler implementation and locking subsystems.
This vulnerability has significant operational impact on systems utilizing io_uring for high-performance I/O operations, particularly in environments where asynchronous I/O processing is critical. The potential for deadlocks and system hangs could affect applications relying heavily on io_uring's resource management features, including database servers, web servers, and high-throughput network applications. The issue is particularly concerning in multi-threaded environments where concurrent access to io_uring resources could trigger the problematic code path, leading to system instability and potential denial of service conditions.
The fix addresses the core issue by ensuring that blocking operations are not attempted when a task is not in TASK_RUNNING state, which aligns with the kernel's design principle that blocking calls should only occur on tasks that are actively running or in appropriate wait states. This remediation follows established security practices for kernel-level resource management and adheres to the principle of least privilege by preventing invalid state transitions that could lead to system corruption. The solution demonstrates proper state management techniques that prevent race conditions and maintain kernel integrity while preserving the intended functionality of the io_uring subsystem. This vulnerability falls under CWE-362, which addresses concurrent execution using locks and similar issues related to improper synchronization in kernel space operations, and could potentially be leveraged by attackers to create denial of service conditions through careful exploitation of the io_uring resource management pathways.