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 hwmondevice_unregister() 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.
{
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/80xxx/CVE-2026-80660.json",
"cna_assigner": "Linux"
}