CVE-2026-23186

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