CVE-2026-23186

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, notice that hwmon_device_register_with_info() may fail

in which case resource->hwmon_dev will become an error pointer,

so add checks to avoid attempting to unregister the hwmon device

pointer to by it in that case to acpi_power_meter_notify() and

acpi_power_meter_remove().