GHSA-4RPR-P877-FC2P

Vulnerability from github – Published: 2026-08-28 09:31 – Updated: 2026-08-28 09:31
VLAI
Details

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.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-80660"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-28T08:16:51Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (occ) unregister sysfs devices outside occ lock\n\nocc_active(false) and occ_shutdown() unregister sysfs-backed devices while\nocc-\u003elock is held.  hwmon_device_unregister() and sysfs_remove_group() can\nwait for active sysfs callbacks to drain, and those callbacks can enter the\nOCC update path and try to take occ-\u003elock again.  That gives the unregister\npaths the lock ordering occ-\u003elock -\u003e sysfs callback drain, while a callback\nhas the opposite edge sysfs callback -\u003e occ-\u003elock.\n\nThis issue was found by our static analysis tool and then manually\nreviewed against the current tree.\n\nThe grounded PoC kept the real unregister and callback carrier:\n\n  occ_shutdown()\n  hwmon_device_unregister()\n  occ_show_temp_1()\n  occ_update_response()\n\nLockdep reported the circular dependency with occ_shutdown() already\nholding the OCC mutex and hwmon_device_unregister() waiting on the sysfs\nside:\n\n  WARNING: possible circular locking dependency detected\n  ... (sysfs_lock) ... at: hwmon_device_unregister+0x12/0x30 [vuln_msv]\n  ... (\u0026test_occ.lock) ... at: occ_shutdown.constprop.0+0xe/0x40 [vuln_msv]\n  occ_update_response.isra.0+0xb/0x20 [vuln_msv]\n  occ_show_temp_1.constprop.0.isra.0+0x23/0x40 [vuln_msv]\n  *** DEADLOCK ***\n\nSerialize hwmon registration and removal with a separate hwmon_lock.\nUnder that lock, detach occ-\u003ehwmon and update occ-\u003eactive while occ-\u003elock\nis held so concurrent OCC state changes still see a stable state, then\ndrop occ-\u003elock before calling hwmon_device_unregister().  Remove the\ndriver sysfs group before taking occ-\u003elock in occ_shutdown(), so draining\nthe driver attributes cannot wait while the OCC mutex is held.  Also make\nOCC update callbacks return -ENODEV after deactivation, so callbacks that\nalready passed sysfs active protection do not poll the hardware after\nteardown has detached the hwmon device.",
  "id": "GHSA-4rpr-p877-fc2p",
  "modified": "2026-08-28T09:31:48Z",
  "published": "2026-08-28T09:31:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80660"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2092952f22a7da98e76e84139ae202b1fc7ba899"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2a4c80ff3571498ec6a916273304b6650026b1b0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7ee43ec8e6774774abbe9dc3027225e01bc964a5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e31408734332b8cc611342cdaaab6ba492180156"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e7fd81e9fb1fe476d2131fec66c1138457810ed4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f0aad157576da199c146c1bb266442befa7912ca"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Loading…