CVE-2026-80660: hwmon: (occ) unregister sysfs devices outside occ lock
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (occ) unregister sysfs devices outside occ lock
occactive(false) and occshutdown() unregister sysfs-backed devices while occ->lock is held. hwmondeviceunregister() and sysfsremovegroup() can wait for active sysfs callbacks to drain, and those callbacks can enter the OCC update path and try to take occ->lock again. That gives the unregister paths the lock ordering occ->lock -> sysfs callback drain, while a callback has the opposite edge sysfs callback -> occ->lock.
This issue was found by our static analysis tool and then manually reviewed against the current tree.
The grounded PoC kept the real unregister and callback carrier:
occshutdown() hwmondeviceunregister() occshowtemp1() occupdateresponse()
Lockdep reported the circular dependency with occshutdown() already holding the OCC mutex and hwmondeviceunregister() waiting on the sysfs side:
WARNING: possible circular locking dependency detected ... (sysfslock) ... at: hwmondeviceunregister+0x12/0x30 [vulnmsv] ... (&testocc.lock) ... at: occshutdown.constprop.0+0xe/0x40 [vulnmsv] occupdateresponse.isra.0+0xb/0x20 [vulnmsv] occshowtemp1.constprop.0.isra.0+0x23/0x40 [vulnmsv] DEADLOCK
Serialize hwmon registration and removal with a separate hwmonlock. Under that lock, detach occ->hwmon and update occ->active while occ->lock is held so concurrent OCC state changes still see a stable state, then drop occ->lock before calling hwmondeviceunregister(). Remove the driver sysfs group before taking occ->lock in occshutdown(), so draining the driver attributes cannot wait while the OCC mutex is held. Also make OCC update callbacks return -ENODEV after deactivation, so callbacks that already passed sysfs active protection do not poll the hardware after teardown has detached the hwmon device.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Modify the driver to avoid circular locking: remove hwmon_device_unregister() from while holding occ->lock. Instead, wait for sysfs active callbacks to drain, detach occ->hwmon while holding a stable state, drop occ->lock before calling hwmon_device_unregister(), and protect hwmon register/unregister with a separate hwmon_lock.
Linux kernel hwmon (occ) driver Locking order = Serialize hwmon registration/removal with a separate hwmon_lock; in occ_shutdown, drain sysfs active callbacks and drop occ->lock before calling hwmon_device_unregister()
Event History
Frequently Asked Questions
Which systems are exposed to this locking issue?
Systems using the Linux kernel OCC hwmon driver are affected when OCC devices are deactivated or shut down while sysfs callbacks for those devices are active.
What conditions trigger the deadlock risk?
The risk requires concurrent activity: an OCC shutdown or occ_active(false) path holds the OCC mutex while unregistering sysfs-backed devices, and an active sysfs callback enters the OCC update path and attempts to acquire the same mutex.
How can the issue be detected in an affected kernel?
Lockdep can report a possible circular locking dependency involving the sysfs lock and the OCC mutex. The reported call paths include occ_shutdown(), hwmon_device_unregister(), occ_show_temp_1(), and occ_update_response().
What remediation is available?
The vulnerability is resolved in Linux kernel changes referenced by the listed stable kernel commits. Apply the applicable upstream or stable-kernel fix rather than relying on concurrent sysfs activity being absent.