CVE-2026-80660
Vulnérabilité non évaluée dans Linux (Linux)
Description
In the Linux kernel, the following vulnerability has been resolved: hwmon: (occ) unregister sysfs devices outside occ lock occ_active(false) and occ_shutdown() unregister sysfs-backed devices while occ->lock is held. hwmon_device_unregister() and sysfs_remove_group() 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: occ_shutdown() hwmon_device_unregister() occ_show_temp_1() occ_update_response() Lockdep reported the circular dependency with occ_shutdown() already holding the OCC mutex and hwmon_device_unregister() waiting on the sysfs side: WARNING: possible circular locking dependency detected ... (sysfs_lock) ... at: hwmon_device_unregister+0x12/0x30 [vuln_msv] ... (&test_occ.lock) ... at: occ_shutdown.constprop.0+0xe/0x40 [vuln_msv] occ_update_response.isra.0+0xb/0x20 [vuln_msv] occ_show_temp_1.constprop.0.isra.0+0x23/0x40 [vuln_msv] *** DEADLOCK *** Serialize hwmon registration and removal with a separate hwmon_lock. 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 hwmon_device_unregister(). Remove the driver sysfs group before taking occ->lock in occ_shutdown(), 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.
Gravité et risque d'exploitation
CVE-2026-80660 obtient un score CVSS de 0.0/10, soit une gravité non évaluée. Selon le modèle EPSS, la probabilité qu'elle soit exploitée dans les 30 prochains jours est de 0.21 %, ce qui la place devant 11.1 % des CVE référencées.
Que faire ?
- Vérifiez si Linux (versions <=6.1.*, 7.1.5, 6.18.40, <=6.12.*, <7ee43ec8e6774774abbe9dc3027225e01bc964a5, 0, <=7.1.*, 5.19, <e7fd81e9fb1fe476d2131fec66c1138457810ed4, <f0aad157576da199c146c1bb266442befa7912ca, 5.15.216, <e31408734332b8cc611342cdaaab6ba492180156, 6.1.178, <2092952f22a7da98e76e84139ae202b1fc7ba899, 6.12.97, <=6.6.*, <2a4c80ff3571498ec6a916273304b6650026b1b0, 849b0156d9960da628a06756bb920d9571c15e66, <5.16, <=6.18.*, 6.6.145, <5.19, <=*, 7.2, bc8a32726774286325b0cb0daab55b682cafc1ef) est présent sur votre parc.
- Appliquez le correctif ou la version corrigée indiqués dans les références de l'éditeur.
- À défaut de correctif, limitez l'exposition (filtrage réseau, désactivation du composant).
- Automatisez la détection : les agents CVE Heimdall (gratuits, open source) corrèlent l'inventaire de vos serveurs avec la base CVE.
Références
- https://git.kernel.org/stable/c/2a4c80ff3571498ec6a916273304b6650026b1b0
- https://git.kernel.org/stable/c/e7fd81e9fb1fe476d2131fec66c1138457810ed4
- https://git.kernel.org/stable/c/2092952f22a7da98e76e84139ae202b1fc7ba899
- https://git.kernel.org/stable/c/f0aad157576da199c146c1bb266442befa7912ca
- https://git.kernel.org/stable/c/7ee43ec8e6774774abbe9dc3027225e01bc964a5
- https://git.kernel.org/stable/c/e31408734332b8cc611342cdaaab6ba492180156