Skip to content
Heist/ feed
Back to feed
UnratedFix available

hwmon: (acpi_power_meter) Fix deadlocks related to acpi_power_meter_notify()

Type: advisorySources: OSV

In the Linux kernel, the following vulnerability has been resolved: hwmon: (acpi_power_meter) Fix deadlocks related to acpi_power_meter_notify() The acpi_power_meter driver's .notify() callback function, acpi_power_meter_notify(), calls hwmon_device_unregister() under a lock that is also acquired by callbacks in sysfs attributes of the device being unregistered which is prone to deadlocks between sysfs access and device removal. Address this by moving the hwmon device removal in acpi_power_meter_notify() outside the lock in question, but notice that doing it alone is not sufficient because two concurrent METER_NOTIFY_CONFIG notifications may be attempting to remove the same device at the same time. To prevent that from happening, add a new lock serializing the execution of the switch () statement in acpi_power_meter_notify(). For simplicity, it is a static mutex which should not be a problem from the performance perspective. The new lock also allows the hwmon_device_register_with_info() in acpi_power_meter_notify() to be called outside the inner lock because it prevents the other notifications handled by that function from manipulating the "resource" object while the hwmon device based on it is being registered. The sending of ACPI netlink messages from acpi_power_meter_notify() is serialized by the new lock too which generally helps to ensure that the order of handling firmware notifications is the same as the order of sending netlink messages related to them. In addition, n

Products
Kernel
Affected versions
Not specified
Fixed versions
6.18.10
CVEs
CVE-2026-23186
Confirmed fixed CVEs
Not specified
Updated in this feed
3 Nov 2026, 17:38 UTC · Revision 1

Source evidence

hwmon: (acpi_power_meter) Fix deadlocks related to acpi_power_meter_notify()

core-osv · Original source

Published 14 Feb 2026, 16:27 UTC

In the Linux kernel, the following vulnerability has been resolved: hwmon: (acpi_power_meter) Fix deadlocks related to acpi_power_meter_notify() The acpi_power_meter driver's .notify() callback function, acpi_power_meter_notify(), calls hwmon_device_unregister() under a lock that is also acquired by callbacks in sysfs attributes of the device being unregistered which is prone to deadlocks between sysfs access and device removal. Address this by moving the hwmon device removal in acpi_power_meter_notify() outside the lock in question, but notice that doing it alone is not sufficient because two concurrent METER_NOTIFY_CONFIG notifications may be attempting to remove the same device at the same time. To prevent that from happening, add a new lock serializing the execution of the switch () statement in acpi_power_meter_notify(). For simplicity, it is a static mutex which should not be a problem from the performance perspective. The new lock also allows the hwmon_device_register_with_info() in acpi_power_meter_notify() to be called outside the inner lock because it prevents the other notifications handled by that function from manipulating the "resource" object while the hwmon device based on it is being registered. The sending of ACPI netlink messages from acpi_power_meter_notify() is serialized by the new lock too which generally helps to ensure that the order of handling firmware notifications is the same as the order of sending netlink messages related to them. In addition, n

osv:CVE-2026-23186

Kernel

Fixed versions: 6.18.10

Complete source record
{
  "id": "5d6cf1ab609ced8afc88d10191da0451984c2a22d0c658ba0e007a3199a579bd",
  "url": "https://osv.dev/vulnerability/CVE-2026-23186",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "hwmon: (acpi_power_meter) Fix deadlocks related to acpi_power_meter_notify()",
    "summary": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (acpi_power_meter) Fix deadlocks related to acpi_power_meter_notify() The acpi_power_meter driver's .notify() callback function, acpi_power_meter_notify(), calls hwmon_device_unregister() under a lock that is also acquired by callbacks in sysfs attributes of the device being unregistered which is prone to deadlocks between sysfs access and device removal. Address this by moving the hwmon device removal in acpi_power_meter_notify() outside the lock in question, but notice that doing it alone is not sufficient because two concurrent METER_NOTIFY_CONFIG notifications may be attempting to remove the same device at the same time. To prevent that from happening, add a new lock serializing the execution of the switch () statement in acpi_power_meter_notify(). For simplicity, it is a static mutex which should not be a problem from the performance perspective. The new lock also allows the hwmon_device_register_with_info() in acpi_power_meter_notify() to be called outside the inner lock because it prevents the other notifications handled by that function from manipulating the \"resource\" object while the hwmon device based on it is being registered. The sending of ACPI netlink messages from acpi_power_meter_notify() is serialized by the new lock too which generally helps to ensure that the order of handling firmware notifications is the same as the order of sending netlink messages related to them. In addition, n",
    "evidence": "osv:CVE-2026-23186",
    "products": [
      {
        "name": {
          "value": "Kernel",
          "evidence": "/affected/1/package/name"
        },
        "prerequisites": [],
        "fixed_versions": [
          {
            "value": "6.18.10",
            "evidence": "/affected/1/ranges"
          }
        ],
        "affected_versions": []
      }
    ],
    "severity": "unknown",
    "structured": {
      "id": "CVE-2026-23186",
      "aliases": [
        "CVE-2026-23186"
      ],
      "affected": [
        {
          "ranges": [
            {
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "type": "GIT",
              "events": [
                {
                  "introduced": "16746ce8adfe04f9ff8df75c1133286ba93c0e17"
                },
                {
                  "fixed": "8860ddf0e07be37169d4ef9f2618e39fca934a66"
                },
                {
                  "fixed": "615901b57b7ef8eb655f71358f7e956e42bcd16b"
                }
              ]
            }
          ],
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-23186.json"
          }
        },
        {
          "ranges": [
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.15.0"
                },
                {
                  "fixed": "6.18.10"
                }
              ]
            }
          ],
          "package": {
            "name": "Kernel",
            "ecosystem": "Linux"
          },
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-23186.json"
          }
        }
      ],
      "modified": "2026-10-28T02:30:31.299585493Z",
      "provider": "osv",
      "references": [
        "https://git.kernel.org/stable/c/615901b57b7ef8eb655f71358f7e956e42bcd16b",
        "https://git.kernel.org/stable/c/8860ddf0e07be37169d4ef9f2618e39fca934a66",
        "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/23xxx/CVE-2026-23186.json",
        "https://nvd.nist.gov/vuln/detail/CVE-2026-23186",
        "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
      ],
      "provider_metadata": {
        "cna_assigner": "Linux",
        "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/23xxx/CVE-2026-23186.json"
      }
    },
    "related_cves": [
      {
        "value": "CVE-2026-23186",
        "evidence": "/id"
      }
    ],
    "security_relevant": true,
    "severity_evidence": null
  },
  "source_id": "core-osv",
  "document_id": 497926,
  "published_at": "2026-02-14T16:27:15.505+00:00"
}