CVE-2026-97968: hwmon: (corsair-cpro) Create debugfs entries after hwmon registration
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (corsair-cpro) Create debugfs entries after hwmon registration
ccpdebugfsinit() registers debugfs files whose private data is the devm allocated ccp. It runs before hwmondeviceregisterwithinfo(), so when that registration fails, ccpprobe() returns with the files still in place. The HID core then frees ccp, and ccpremove() is not called for a failed probe, so nothing removes them later either. Reading one of the files dereferences the freed pointer.
Create the debugfs entries only after the hwmon device has been registered, so no failing path can leave them behind.
The two version queries stay where they are. They send USB commands without holding ccp->mutex, which is only safe as long as nothing else can call sendusbcmd(); once the hwmon device is registered its callbacks can do so concurrently. Only the debugfs creation moves, and it is told which queries succeeded.
Affected Software
Event History
Frequently Asked Questions
Under what condition can the stale debugfs files be left behind?
This occurs when ccp_probe() creates the debugfs files and hwmon_device_register_with_info() subsequently fails. Because probe failure does not invoke ccp_remove(), the files are not removed before the HID core frees the associated ccp allocation.
What must an attacker or local user do to trigger the unsafe access?
They would need to read one of the Corsair C-Pro driver's debugfs files after the failed probe path has left those entries in place. Reading such a file dereferences the freed ccp pointer.
What does the fix change?
The fix creates the debugfs entries only after successful hwmon device registration, preventing a registration failure from leaving entries backed by freed private data. The two version queries remain before registration because moving them would introduce concurrent USB-command access concerns.