CVE-2022-48868 in Linux
Summary
by MITRE • 08/21/2024
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Let probe fail when workqueue cannot be enabled
The workqueue is enabled when the appropriate driver is loaded and disabled when the driver is removed. When the driver is removed it assumes that the workqueue was enabled successfully and proceeds to free allocations made during workqueue enabling.
Failure during workqueue enabling does not prevent the driver from being loaded. This is because the error path within drv_enable_wq() returns success unless a second failure is encountered during the error path. By returning success it is possible to load the driver even if the workqueue cannot be enabled and allocations that do not exist are attempted to be freed during driver remove.
Some examples of problematic flows: (a)
idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully.
idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().
(b)
idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0.
idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010
Fix the drv_enable_wq() error path by returning the original error that indicates failure of workqueue enabling. This ensures that the probe fails when an error is encountered and the driver remove paths are only attempted when the workqueue was enabled successfully.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 02/17/2026
The vulnerability described in CVE-2022-48868 resides within the Linux kernel's dmaengine subsystem, specifically affecting the Intel Data Center DPU (IDX) driver implementation. This flaw represents a critical issue in driver initialization and resource management that can lead to system instability and potential security implications. The vulnerability stems from improper error handling within the workqueue enabling mechanism during driver probe operations, creating a scenario where drivers can be loaded successfully even when core subsystems fail to initialize properly. This misconfiguration allows subsequent cleanup operations to attempt actions on resources that were never properly allocated, leading to kernel panics and system crashes.
The technical flaw manifests in the drv_enable_wq() function which serves as the primary interface for enabling workqueues during driver initialization. When the driver probe encounters failures during workqueue setup, particularly in functions like idxd_wq_request_irq() that handle interrupt registration, the error handling logic incorrectly returns success status instead of propagating the actual failure. This behavior violates fundamental kernel programming principles where initialization failures should prevent subsequent operations from proceeding. The issue creates a false positive state where the driver believes it has successfully enabled all required resources, when in reality critical subsystems like interrupt handling or percpu reference counters remain uninitialized.
The operational impact of this vulnerability extends beyond simple system crashes to potentially compromise system stability and availability. During driver removal operations, the kernel attempts to free resources that were never actually allocated due to the failed initialization, triggering kernel warnings and BUG messages in the kernel log. The specific scenarios described in the vulnerability report demonstrate how different failure points within the initialization sequence can cause cascading issues. In case (a), the device resource mapping gets freed prematurely during error handling, leading to WARN messages during cleanup operations that reference already freed memory mappings. In case (b), the percpu reference counter initialization is skipped entirely, causing a kernel NULL pointer dereference when cleanup attempts to drop references to uninitialized data structures, resulting in system crashes.
The fix implemented addresses the core issue by ensuring that drv_enable_wq() returns the original error code when workqueue enabling fails, rather than masking the actual failure with a successful return value. This change enforces proper error propagation throughout the driver initialization sequence, preventing drivers from being loaded when critical subsystems cannot be properly configured. The solution aligns with established kernel development practices and security principles that require robust error handling and resource management. This vulnerability classification maps to CWE-252, which covers "Unchecked Return Value" and CWE-476, which addresses "NULL Pointer Dereference" in kernel contexts. The issue also relates to ATT&CK technique T1490, "Inhibit System Recovery" through kernel-level disruptions that can cause system instability and denial of service conditions.
Mitigation strategies for this vulnerability require immediate kernel updates to include the patched driver implementation. System administrators should prioritize applying security patches that address the specific error handling logic in the idxd driver's workqueue enabling functions. Organizations should also implement monitoring systems to detect kernel warnings and BUG messages related to driver initialization failures, as these may indicate the presence of unpatched systems vulnerable to this class of issues. Additionally, proper kernel module loading and unloading sequences should be validated through automated testing procedures to ensure that resource cleanup operations only occur when resources were actually allocated during initialization phases. The fix ensures that driver removal paths are only executed when the corresponding initialization paths have completed successfully, maintaining the integrity of kernel resource management and preventing the cascading failures that could lead to system compromise or denial of service conditions.