Bug 2541169 (CVE-2026-97968)

Summary: CVE-2026-97968 kernel: hwmon: (corsair-cpro) Create debugfs entries after hwmon registration
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: akhatavk, aos-team-art-private, asdas, dpaolell, jdelft, jupierce, lgarciaa, mbiarnes, ppalepu, ppostler, prdhamdh, rhel-process-autobot, sghai, sidsharm, suppawar, vlaad, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in the Linux kernel's Corsair Commander Pro (corsair-cpro) hardware monitoring driver. When device registration fails during initialization, debugfs entries are left registered after the associated device data structure has been freed. A local user with access to the debugfs filesystem can interact with these dangling files to cause a use-after-free condition, resulting in a system crash and Denial of Service (DoS).
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-09-25 10:54:17 UTC 
In the Linux kernel, the following vulnerability has been resolved:

hwmon: (corsair-cpro) Create debugfs entries after hwmon registration

ccp_debugfs_init() registers debugfs files whose private data is the devm
allocated ccp.  It runs before hwmon_device_register_with_info(), so when
that registration fails, ccp_probe() returns with the files still in
place.  The HID core then frees ccp, and ccp_remove() 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 send_usb_cmd(); once the hwmon device is registered its
callbacks can do so concurrently.  Only the debugfs creation moves, and
it is told which queries succeeded.
Comment 1 gkamathe 2026-09-30 04:45:09 UTC 
Upstream advisory:
https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2026/CVE-2026-97968.mbox