CVE-2022-49313 in Linux
Summary
by MITRE • 02/26/2025
In the Linux kernel, the following vulnerability has been resolved:
drivers: usb: host: Fix deadlock in oxu_bus_suspend()
There is a deadlock in oxu_bus_suspend(), which is shown below:
(Thread 1) | (Thread 2) | timer_action() oxu_bus_suspend() | mod_timer() spin_lock_irq() //(1) | (wait a time) ... | oxu_watchdog() del_timer_sync() | spin_lock_irq() //(2) (wait timer to stop) | ...
We hold oxu->lock in position (1) of thread 1, and use del_timer_sync() to wait timer to stop, but timer handler also need oxu->lock in position (2) of thread 2. As a result, oxu_bus_suspend() will block forever.
This patch extracts del_timer_sync() from the protection of spin_lock_irq(), which could let timer handler to obtain the needed lock.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 02/26/2025
The vulnerability identified as CVE-2022-49313 represents a critical deadlock condition within the Linux kernel's USB host controller driver subsystem, specifically affecting the oxu_bus_suspend() function. This issue manifests as a classic circular dependency scenario where two execution threads become permanently blocked, creating a system-wide hang condition that severely impacts device power management capabilities. The vulnerability exists in the USB host controller driver implementation that manages device suspension states, which is a fundamental component of the kernel's power management architecture.
The technical flaw stems from improper locking mechanisms within the USB host controller driver code where the oxu->lock spinlock is acquired in the first thread at position (1) during the oxu_bus_suspend() function execution. The function then invokes del_timer_sync() which waits indefinitely for a timer to stop, but the timer handler function timer_action() attempts to acquire the same oxu->lock at position (2) in the second thread. This creates an unavoidable deadlock scenario where Thread 1 holds the lock while waiting for the timer to stop, and Thread 2 waits for the lock that Thread 1 cannot release due to the ongoing timer operation. This type of deadlock falls under the CWE-362 category of concurrent execution using shared resources without proper synchronization mechanisms.
The operational impact of this vulnerability is significant as it completely prevents the USB host controller from properly suspending devices, which directly affects system power management and battery life on mobile devices. When a system attempts to suspend USB devices through the oxu_bus_suspend() function, the deadlock causes the suspension process to hang indefinitely, potentially leading to system instability, complete system freezes, or forced reboots. This vulnerability particularly affects systems running Linux kernels with USB host controller drivers that implement the oxu_bus_suspend() function, making it a critical issue for embedded systems, mobile devices, and servers that rely on proper USB power management. The vulnerability also impacts the overall system reliability as it can cause cascading failures in power management subsystems.
The fix implemented in this patch addresses the root cause by extracting the del_timer_sync() call from the protection scope of spin_lock_irq(), allowing the timer handler to acquire the necessary lock without being blocked by the suspension process. This modification follows the principle of avoiding nested locking scenarios and ensures proper lock ordering between different kernel subsystems. The solution aligns with the ATT&CK framework's system and network utilities category, specifically addressing privilege escalation through kernel-level vulnerabilities. This type of fix demonstrates the importance of careful lock management in kernel code and the necessity of avoiding lock contention scenarios that can lead to system-wide deadlocks. The remediation approach also reflects best practices for kernel development and follows established guidelines for preventing race conditions and deadlock situations in concurrent kernel subsystems.