Description
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 pmbus_notify(), the code unconditionally casts
every attribute to a struct sensor_device_attribute:

drivers/hwmon/pmbus/pmbus_core.c:pmbus_notify() {
for (i = 0; i < data->num_attributes; i++) {
struct device_attribute *da = to_dev_attr(data->group.attrs[i]);
struct sensor_device_attribute *attr = to_sensor_dev_attr(da);
int index = attr->index;
...
}

However, data->group.attrs can contain other types like struct
pmbus_samples_reg or struct pmbus_sensor, which only embed a base
struct device_attribute.

If da is a struct pmbus_samples_reg, dev_attr is the last member. Casting
it to struct sensor_device_attribute 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 pmbus_sensor, 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 sensor_device_attr in struct pmbus_sensor
and struct pmbus_label. 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.
Published: 2026-08-22
Score: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The vulnerability occurs in the Linux kernel’s hwmon pmbus subsystem. In the notification routine, each device attribute is unconditionally cast to a sensor_device_attribute. When the attribute actually belongs to a different structure such as pmbus_samples_reg or pmbus_sensor, the cast causes the code to read an index field that resides past the end or overlapped with other fields. This type confusion can trigger an out‑of‑bounds read, potentially exposing kernel memory to a local attacker, leading to sensitive data disclosure.

Affected Systems

The flaw is present in any Linux kernel build that implements the hwmon pmbus module and predates the patch commit 0b121de89a99c54bcf516999b04e8531c84f08d5. No specific kernel versions are listed, so all kernels prior to that commit are considered vulnerable.

Risk and Exploitability

The EPSS score is not available and the vulnerability is not listed in the CISA KEV catalog. No public exploit has been reported. The weakness is local and requires the attacker to trigger the notification logic on a pmbus device, which typically needs privileged or kernel‑module access. The potential impact is information disclosure rather than remote code execution; the likelihood of exploitation remains uncertain but could be significant for systems with uncontrolled hwmon access.

Generated by OpenCVE AI on August 22, 2026 at 18:25 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the kernel to a release that incorporates commit 0b121de89a99c54bcf516999b04e8531c84f08d5, which removes the type confusion in the notification logic.
  • If an immediate upgrade is not possible, unload or blacklist the hwmon pmbus module so that the vulnerable notification path is never activated.
  • Restrict access to the pmbus attributes exposed under /sys/class/hwmon/ so that only privileged users can interact with them, and enforce the principle of least privilege via SELinux or AppArmor policies.

Generated by OpenCVE AI on August 22, 2026 at 18:25 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sat, 22 Aug 2026 18:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-201
CWE-839

Sat, 22 Aug 2026 15:45:00 +0000

Type Values Removed Values Added
Description 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 pmbus_notify(), the code unconditionally casts every attribute to a struct sensor_device_attribute: drivers/hwmon/pmbus/pmbus_core.c:pmbus_notify() { for (i = 0; i < data->num_attributes; i++) { struct device_attribute *da = to_dev_attr(data->group.attrs[i]); struct sensor_device_attribute *attr = to_sensor_dev_attr(da); int index = attr->index; ... } However, data->group.attrs can contain other types like struct pmbus_samples_reg or struct pmbus_sensor, which only embed a base struct device_attribute. If da is a struct pmbus_samples_reg, dev_attr is the last member. Casting it to struct sensor_device_attribute 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 pmbus_sensor, 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 sensor_device_attr in struct pmbus_sensor and struct pmbus_label. 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.
Title hwmon: (pmbus) Fix type confusion in notification logic
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-22T15:33:07.779Z

Reserved: 2026-08-15T05:44:03.928Z

Link: CVE-2026-74711

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-08-22T16:16:45.853

Modified: 2026-08-22T16:16:45.853

Link: CVE-2026-74711

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-08-22T18:30:16Z

Weaknesses
  • CWE-201

    Insertion of Sensitive Information Into Sent Data

  • CWE-839

    Numeric Range Comparison Without Minimum Check