CVE-2025-21952 in Linux
Summary
by MITRE • 04/01/2025
In the Linux kernel, the following vulnerability has been resolved:
HID: corsair-void: Update power supply values with a unified work handler
corsair_void_process_receiver can be called from an interrupt context, locking battery_mutex in it was causing a kernel panic. Fix it by moving the critical section into its own work, sharing this work with battery_add_work and battery_remove_work to remove the need for any locking
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 02/01/2026
The vulnerability identified as CVE-2025-21952 resides within the Linux kernel's Human Interface Device (HID) subsystem, specifically affecting the corsair_void driver implementation. This driver manages Corsair Void gaming headsets that utilize wireless connectivity and battery monitoring capabilities. The issue manifests in how the driver handles power supply updates and battery state management through the hid_device structure, creating a critical race condition that can lead to system instability. The vulnerability demonstrates a fundamental flaw in interrupt handling and synchronization mechanisms within the kernel's device management framework, potentially compromising the integrity of the entire system.
The technical root cause stems from the corsair_void_process_receiver function which executes within an interrupt context but attempts to acquire the battery_mutex lock during its execution. This design creates a direct conflict with kernel locking principles where interrupt handlers should avoid acquiring locks that could lead to deadlocks or system panics. The mutex acquisition occurs in a context where the kernel cannot safely perform the locking operation, particularly when the interrupt handler is processing events from the wireless receiver. This violates the fundamental requirement that interrupt handlers must remain lightweight and avoid operations that could block or require complex synchronization primitives.
The operational impact of this vulnerability extends beyond simple device malfunction to potentially cause complete system crashes or panics. When the interrupt handler attempts to lock the battery_mutex, it triggers a kernel panic due to the improper locking sequence, effectively bringing the entire system to a halt. This represents a critical security flaw that could be exploited by malicious actors to cause denial of service attacks against systems running affected kernel versions, particularly those with Corsair Void headsets connected. The vulnerability affects the reliability of the system's power management subsystem and demonstrates poor adherence to kernel development best practices.
The fix implemented addresses this issue by introducing a unified work queue handler that moves the critical section operations outside of the interrupt context. This approach follows established kernel design patterns and removes the need for direct mutex locking within interrupt handlers. The solution employs a work queue mechanism that allows the battery state updates to be processed asynchronously, eliminating the race condition while maintaining proper device functionality. This mitigation aligns with the principle of avoiding locking in interrupt contexts as recommended by the Linux kernel documentation and security guidelines. The implementation leverages existing work queue infrastructure and shares the same work handler between battery_add_work and battery_remove_work operations, reducing code duplication while ensuring proper synchronization. This approach directly addresses the common weakness identified in CWE-362, which focuses on race conditions in concurrent programming, and follows ATT&CK technique T1499.001 for system shutdown and denial of service operations.
The resolution demonstrates proper kernel development practices by ensuring that interrupt handlers remain lightweight and do not perform operations that could lead to system instability. The fix maintains the functional integrity of the Corsair Void headset driver while eliminating the kernel panic condition that could occur during normal device operation. This vulnerability highlights the importance of understanding the execution context requirements for different kernel subsystems and the critical need for proper synchronization mechanisms in device drivers. The implementation serves as a model for how similar issues can be resolved in other kernel subsystems where interrupt contexts must interact with shared resources.