CVE-2024-36944 in Linux
Summary
by MITRE • 05/30/2024
In the Linux kernel, the following vulnerability has been resolved:
Reapply "drm/qxl: simplify qxl_fence_wait"
This reverts commit 07ed11afb68d94eadd4ffc082b97c2331307c5ea.
Stephen Rostedt reports: "I went to run my tests on my VMs and the tests hung on boot up. Unfortunately, the most I ever got out was:
[ 93.607888] Testing event system initcall: OK
[ 93.667730] Running tests on all trace events:
[ 93.669757] Testing all events: OK
[ 95.631064] ------------[ cut here ]------------
Timed out after 60 seconds"
and further debugging points to a possible circular locking dependency between the console_owner locking and the worker pool locking.
Reverting the commit allows Steve's VM to boot to completion again.
[ This may obviously result in the "[TTM] Buffer eviction failed"
messages again, which was the reason for that original revert. But at this point this seems preferable to a non-booting system... ]
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/07/2024
The vulnerability CVE-2024-36944 represents a critical boot-time deadlock condition within the Linux kernel's graphics subsystem, specifically affecting the qxl driver used in virtualized environments. This issue emerged from an attempted optimization that introduced a circular locking dependency between console_owner and worker pool locking mechanisms. The problem manifests as a system hang during early boot phases, preventing successful system initialization and rendering affected virtual machines non-functional. The root cause stems from a flawed reapplication of a drm/qxl driver optimization that was originally intended to simplify fence waiting operations but inadvertently created a deadlock scenario.
The technical flaw involves a circular dependency in kernel locking primitives where the console_owner lock and worker pool locks create a mutual waiting condition that cannot be resolved. When the system attempts to initialize graphics components during boot, the qxl driver's fence waiting implementation triggers this circular dependency, causing the kernel to hang indefinitely. This type of deadlock represents a classic concurrency issue that can be categorized under CWE-367, which addresses time-of-check to time-of-use (TOCTOU) vulnerabilities and improper locking mechanisms. The debugging evidence points to a timeout after 60 seconds, indicating that the kernel's scheduler detects the deadlock and attempts to prevent a complete system freeze while still allowing the boot process to hang.
The operational impact of this vulnerability is severe, particularly in virtualized environments where qxl drivers are commonly used for graphics acceleration in virtual machines. Systems affected by this vulnerability cannot complete their boot process, resulting in complete system unavailability until the problematic kernel version is replaced or the specific commit is reverted. This affects cloud computing platforms, virtual desktop infrastructures, and any deployment relying on qxl graphics drivers for virtualized graphics processing. The vulnerability directly impacts the availability and reliability of systems, as evidenced by the reported timeout behavior and the need for manual intervention through commit reversion to restore functionality. Organizations running virtualized environments must urgently assess their kernel versions and apply patches to avoid system downtime.
Mitigation strategies for CVE-2024-36944 involve immediate rollback of the problematic commit 07ed11afb68d94eadd4ffc082b97c2331307c5ea or upgrading to a kernel version that properly addresses the circular locking dependency. The recommended approach aligns with ATT&CK technique T1490, which involves system network configuration modifications to prevent or remediate system-level issues. System administrators should implement a phased rollback strategy across their virtualized environments, ensuring that all affected VMs are updated before deploying new kernel versions. Additionally, monitoring systems should be configured to detect early boot hangs and alert administrators to potential lockup conditions. The vulnerability demonstrates the importance of thorough testing in kernel modifications, particularly for graphics drivers that operate in complex multi-threaded environments where locking dependencies can have cascading effects throughout the system. Organizations should also consider implementing automated testing procedures for graphics drivers in virtualized environments to prevent similar issues from being introduced into production systems.