CVE-2024-56545 in Linux
Summary
by MITRE • 12/27/2024
In the Linux kernel, the following vulnerability has been resolved:
HID: hyperv: streamline driver probe to avoid devres issues
It was found that unloading 'hid_hyperv' module results in a devres complaint:
... hv_vmbus: unregistering driver hid_hyperv ------------[ cut here ]------------
WARNING: CPU: 2 PID: 3983 at drivers/base/devres.c:691 devres_release_group+0x1f2/0x2c0 ... Call Trace: ? devres_release_group+0x1f2/0x2c0 ? __warn+0xd1/0x1c0 ? devres_release_group+0x1f2/0x2c0 ? report_bug+0x32a/0x3c0 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x18/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? devres_release_group+0x1f2/0x2c0 ? devres_release_group+0x90/0x2c0 ? rcu_is_watching+0x15/0xb0 ? __pfx_devres_release_group+0x10/0x10 hid_device_remove+0xf5/0x220 device_release_driver_internal+0x371/0x540 ? klist_put+0xf3/0x170 bus_remove_device+0x1f1/0x3f0 device_del+0x33f/0x8c0 ? __pfx_device_del+0x10/0x10 ? cleanup_srcu_struct+0x337/0x500 hid_destroy_device+0xc8/0x130 mousevsc_remove+0xd2/0x1d0 [hid_hyperv]
device_release_driver_internal+0x371/0x540 driver_detach+0xc5/0x180 bus_remove_driver+0x11e/0x2a0 ? __mutex_unlock_slowpath+0x160/0x5e0 vmbus_driver_unregister+0x62/0x2b0 [hv_vmbus]
...
And the issue seems to be that the corresponding devres group is not allocated. Normally, devres_open_group() is called from __hid_device_probe() but Hyper-V HID driver overrides 'hid_dev->driver' with 'mousevsc_hid_driver' stub and basically re-implements __hid_device_probe() by calling hid_parse() and hid_hw_start() but not devres_open_group(). hid_device_probe() does not call __hid_device_probe() for it. Later, when the driver is removed, hid_device_remove() calls devres_release_group() as it doesn't check whether hdev->driver was initially overridden or not.
The issue seems to be related to the commit 62c68e7cee33 ("HID: ensure timely release of driver-allocated resources") but the commit itself seems to be correct.
Fix the issue by dropping the 'hid_dev->driver' override and using hid_register_driver()/hid_unregister_driver() instead. Alternatively, it would have been possible to rely on the default handling but HID_CONNECT_DEFAULT implies HID_CONNECT_HIDRAW and it doesn't seem to work for mousevsc as-is.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 12/23/2025
The vulnerability described in CVE-2024-56545 resides within the Linux kernel's HID (Human Interface Device) subsystem, specifically affecting the Hyper-V HID driver implementation. This issue manifests during module unloading operations when the hid_hyperv module attempts to release device resources, resulting in kernel warnings and potential instability. The problem stems from improper resource management during the driver probe and removal sequences, creating a devres (device resource) complaint that can lead to system crashes or inconsistent device states.
The technical flaw occurs in the Hyper-V HID driver's implementation where the driver overrides the hid_dev->driver field with a mousevsc_hid_driver stub and reimplements the probe functionality without properly allocating the devres group. Typically, devres_open_group() is called from __hid_device_probe() during normal driver initialization, but the Hyper-V implementation bypasses this by directly calling hid_parse() and hid_hw_start() without the resource group allocation. This creates a disconnect where the driver removal process attempts to release resources through devres_release_group() but fails because no corresponding devres group was allocated during the overridden probe sequence.
The operational impact of this vulnerability extends beyond simple kernel warnings to potentially destabilize systems running Hyper-V environments where HID devices are actively used. When the hid_hyperv module is unloaded, the kernel's device resource management subsystem encounters a NULL pointer dereference or resource release failure, which can manifest as kernel oops messages, system hangs, or in severe cases, complete system crashes. This issue is particularly concerning in virtualized environments where Hyper-V drivers are frequently loaded and unloaded during VM operations, potentially leading to cascading failures in virtual machine management.
The fix for this vulnerability involves restructuring the driver initialization and cleanup processes to properly handle device resource allocation. The recommended approach eliminates the manual driver override mechanism and instead employs the standard hid_register_driver()/hid_unregister_driver() functions for proper driver registration and unregistration. This solution aligns with the established patterns for HID driver development and ensures that all resource management operations follow the standard kernel device resource lifecycle. Alternative approaches such as relying on default HID handling with HID_CONNECT_DEFAULT could work but are not suitable for the mousevsc driver implementation due to its specific requirements for HIDRAW integration.
This vulnerability maps to CWE-457: Use of Uninitialized Variable and CWE-755: Improper Handling of Exceptional Conditions within the Common Weakness Enumeration framework. The issue also relates to ATT&CK technique T1490: Inhibit System Recovery, as the improper resource management could lead to system instability and potential denial of service conditions. The root cause demonstrates poor adherence to kernel driver development best practices regarding resource lifecycle management, particularly in virtualized environments where driver loading and unloading operations occur frequently. The fix addresses these concerns by ensuring proper resource allocation and deallocation patterns that align with kernel subsystem expectations and maintain system stability during dynamic driver operations.