CVE-2026-74711: hwmon: (pmbus) Fix type confusion in notification logic

Published Aug 22, 2026
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

hwmon: (pmbus) Fix type confusion in notification logic

Sashiko reports:

At the start of the loop in pmbusnotify(), the code unconditionally casts every attribute to a struct sensordeviceattribute:

drivers/hwmon/pmbus/pmbuscore.c:pmbusnotify() { for (i = 0; i < data->numattributes; i++) { struct deviceattribute da = todevattr(data->group.attrs[i]); struct sensordeviceattribute attr = tosensordevattr(da); int index = attr->index; ... }

However, data->group.attrs can contain other types like struct pmbussamplesreg or struct pmbussensor, which only embed a base struct deviceattribute.

If da is a struct pmbussamplesreg, devattr is the last member. Casting it to struct sensordeviceattribute and reading the index field appears to access memory past the end of the allocation, which might trigger a slab-out-of-bounds read.

Additionally, if da is a struct pmbussensor, casting it causes the index field to overlap with the page, phase, and reg fields. Could this produce a garbage mask on little-endian systems that spuriously matches the target reg, page, and flags during an alert?

Fix the problem by using struct sensordeviceattr in struct pmbussensor and struct pmbuslabel. Since those attributes never trigger a notification, set the value of attr->index to -1 for them. Use this value to distinguish from boolean attributes which can trigger a notification and use the index field to encode mask, page, and register values.

Affected Software

1 affected component
Linux Linux kernel

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Configuration

    In pmbus_notify(), avoid unconditionally casting group attributes to struct sensor_device_attribute. When iterating over data->group.attrs[i], ensure only sensor device attributes use sensor_device_attr conversion; for other attribute types (including those that only embed a base reg/page/flags or are struct pmbus_samples_reg), set the notification trigger index to -1 (i.e., force attr->index to -1) so they never trigger a notification and cannot cause slab out-of-bounds reads/type confusion.

    Linux kernel drivers/hwmon/pmbus/pmbus_core.c (pmbus_notify notification logic) attr->index handling / type confusion fix = Set attr->index to -1 for attributes that are not struct sensor_device_attribute (e.g., struct pmbus_samples_reg or other non-sensor_device_attribute types)
  2. Compensating control

    Mitigate risk on little-endian systems by ensuring pmbus notification attributes that rely on casting do not spuriously match targets due to a garbage mask; treat non-sensor_device_attribute entries as non-notifiable by forcing their attr->index to -1 (per the described fix).

Event History

Aug 22, 2026
CVE Published
via MITRE·03:33 PM
Data Sourced
via MITRE·03:33 PM
Description
Data Sourced
via NVD·04:16 PM
Description

Frequently Asked Questions

1

Which systems are most relevant to this issue?

Systems using the Linux kernel PMBus hwmon driver and its notification handling are relevant. The unsafe path occurs when the driver's attribute group includes PMBus-specific attribute types such as pmbus_samples_reg or pmbus_sensor rather than only sensor_device_attribute entries.

2

What condition triggers the faulty behavior?

The notification loop must process an attribute that is not actually a sensor_device_attribute. The code then interprets that object as the wrong type and reads an index field from an invalid or overlapping memory location.

3

What are the potential effects of the incorrect cast?

For a pmbus_samples_reg attribute, the cast can read beyond the allocation and may cause a slab out-of-bounds read. For a pmbus_sensor attribute, overlapping fields can produce a garbage mask that may spuriously match an alert's register, page, and flags.

4

Is a fix available?

The issue is described as resolved, with fixes referenced in stable commits 821f6416e69782fa662aff94b5ea52c943042790, 0b121de89a99c54bcf516999b04e8531c84f08d5, and 59bd68ab05a8f9c9a60b6ec44682084184803ff4. The provided data does not map those commits to specific kernel release versions.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203