Cloudanix VulnDB

CVE-2026-64087

Medium · 5.5

CVSS

5.5

EPSS

0.1%

Published

Jul 19, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

Some Linux systems using a specific power-management chip driver can crash or become unstable if the chip reports invalid diagnostic data.

Exploitation
Physical Access
Attacker needs
Physical Access
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Buffer Overflow
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

This flaw is an out-of-bounds memory access in the Linux kernel ADM1266 PMBus hardware-monitoring driver. The driver trusts a record_count value returned by the ADM1266 BLACKBOX_INFO command and uses it to copy blackbox records into a fixed-size 2048-byte kernel buffer that can only hold 32 records. If the device, firmware, bus, or a malicious responder reports more than 32 records, the kernel loop can read or write past the allocated buffer. The most likely impact is kernel memory corruption and denial of service through an oops or panic; in highly controlled conditions, kernel memory corruption may create a path toward privilege escalation, though no public exploit maturity is reported.

Why it matters to the business

Systems using the affected Linux kernel driver with ADM1266-compatible PMBus devices could experience unexpected crashes or instability when hardware-monitoring or nvmem blackbox data is read. The business risk is mainly operational disruption on servers, appliances, embedded platforms, or industrial systems that rely on these power-management components. Broad internet-scale exploitation is unlikely because exploitation generally requires influence over a local hardware bus, device firmware, or a malicious/compromised peripheral. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, so remediation should be prioritized based on whether affected hardware and the adm1266 driver are present in critical systems.

How an attack unfolds

An attacker would need a way to influence the ADM1266 PMBus response seen by the Linux kernel, such as through malicious hardware, compromised device firmware, bus-level manipulation, a faulty/non-responsive PMBus device returning 0xff, or a supply-chain implant. Once the vulnerable adm1266 driver is bound to the device, the attacker causes a read of the ADM1266 blackbox nvmem data, commonly through kernel hardware-monitoring or nvmem interfaces. The driver sends BLACKBOX_INFO and receives a malformed record_count greater than the supported maximum of 32. Because vulnerable kernels do not reject the implausible value before looping, the driver continues copying blackbox records beyond the end of the allocated dev_mem buffer. This can corrupt adjacent kernel memory and may crash the system; with sufficient control over timing and returned data, an attacker may attempt to shape the corruption for further kernel-level impact.

How to fix it

Upgrade to a Linux kernel version that includes the ADM1266 PMBus driver fix which caps record_count at ADM1266_BLACKBOX_MAX_RECORDS and returns an error for larger values. If a vendor distribution kernel is used, apply the vendor security update rather than relying only on upstream version numbers. Where immediate patching is not possible, reduce exposure by disabling or preventing loading of the adm1266 driver if the hardware is not required, restricting access to nvmem and hardware-monitoring interfaces to trusted administrators, and avoiding untrusted or recently modified PMBus/I2C devices and firmware. On appliances and embedded systems, obtain updated firmware or OS images from the platform vendor because the vulnerable code may be bundled into a customized kernel.

How to confirm the fix worked

Confirm whether the system is exposed by checking whether the adm1266 driver is present, loaded, or bound to hardware, for example by reviewing loaded kernel modules, kernel configuration, sysfs hardware-monitoring devices, and device-tree or board configuration. Confirm remediation by verifying the running kernel package or vendor advisory includes the fix for rejecting ADM1266 blackbox record_count values greater than 32. Source-based validation can check that adm1266_nvmem_read_blackbox() rejects values above ADM1266_BLACKBOX_MAX_RECORDS before entering the read loop. After patching, review kernel logs while exercising normal hardware-monitoring workflows to confirm there are no oops, KASAN, slab, or pmbus/adm1266 errors. Do not attempt malformed PMBus fuzzing on production systems because it may crash vulnerable kernels or affect hardware management functions.

Typical attack path

  1. Gain the ability to influence an ADM1266-compatible PMBus/I2C device response through malicious hardware, compromised firmware, bus manipulation, or a faulty device condition.
  2. Ensure the vulnerable Linux kernel adm1266 driver is loaded and bound to the target PMBus device.
  3. Trigger a read of the ADM1266 blackbox nvmem data through the relevant kernel-exposed hardware monitoring or nvmem interface.
  4. Return a malformed BLACKBOX_INFO response with record_count greater than 32, or cause the bus/device to return an implausible value such as 0xff.
  5. Allow the vulnerable driver loop to process more records than the fixed 2048-byte buffer supports.
  6. Cause kernel memory corruption, leading to a kernel oops, panic, system instability, or potentially further exploitation under controlled conditions.

How to detect it

There is no reliable remote network indicator for this vulnerability because exploitation depends on local hardware-bus or device-response manipulation. To investigate possible prior exploitation, review kernel logs, persistent journal data, crash dumps, pstore records, and hardware-management logs for kernel oops or panic events involving adm1266, pmbus, nvmem, BLACKBOX_INFO, or adm1266_nvmem_read_blackbox. Look for KASAN, slab, general-protection fault, page fault, or memory-corruption messages around the time hardware-monitoring tools, inventory agents, nvmem reads, BMC workflows, or firmware updates ran. Review administrative command history and audit logs for reads of sysfs nvmem or hwmon paths associated with ADM1266 devices. Correlate suspicious events with physical maintenance, device replacement, firmware changes, unexplained I2C/PMBus errors, or repeated system resets. Absence of these artifacts does not prove non-exploitation because a kernel crash may not preserve detailed logs.

  • adm1266_nvmem_read_blackbox
  • adm1266
  • pmbus
  • BLACKBOX_INFO
  • KASAN: slab-out-of-bounds
  • KASAN: out-of-bounds
  • BUG: kernel NULL pointer dereference
  • general protection fault
  • kernel panic
  • Oops:
  • nvmem
  • /sys/bus/nvmem/devices/
  • /sys/class/hwmon/
  • /sys/bus/i2c/drivers/adm1266/
  • CONFIG_SENSORS_ADM1266

What your security team should do

  • Inventory Linux systems, appliances, and embedded platforms that include ADM1266-compatible PMBus hardware or load the adm1266 kernel driver.
  • Prioritize patching for critical infrastructure, high-availability systems, hardware-management controllers, and systems where physical or firmware supply-chain risk is meaningful.
  • Apply the relevant Linux distribution or appliance vendor kernel update as soon as practical, even though there is no current KEV listing and public exploit maturity is reported as none.
  • If the driver is not needed, blacklist or disable the adm1266 module and remove unnecessary exposure of nvmem/hwmon interfaces.
  • Restrict local administrative access capable of reading hardware nvmem interfaces and tightly control firmware updates for PMBus/I2C-attached devices.
  • Monitor for kernel oops, panic, KASAN, slab-out-of-bounds, and pmbus/adm1266 messages, especially after hardware maintenance, firmware updates, or unexplained system resets.
  • Coordinate with hardware and platform vendors to determine whether ADM1266 devices are present and whether their firmware could return malformed BLACKBOX_INFO values.

The record

In the Linux kernel, the following vulnerability has been resolved: hwmon: (pmbus/adm1266) reject implausible blackbox record_count adm1266_nvmem_read_blackbox() loops over a record_count that comes straight from byte 3 of the BLACKBOX_INFO response. The destination buffer is data->dev_mem, sized for the nvmem cell's declared 2048 bytes (ADM1266_BLACKBOX_MAX_RECORDS * ADM1266_BLACKBOX_SIZE = 32 * 64). A device that reports a record_count greater than 32 -- whether due to firmware bugs, bus corruption, or a non-responsive slave returning 0xff -- would walk read_buff past the end of the dev_mem allocation on the trailing iterations. Cap record_count at ADM1266_BLACKBOX_MAX_RECORDS (introduced here) before entering the loop and return -EIO on any larger value, so a malformed BLACKBOX_INFO response cannot drive the loop out of bounds.

Affected packages

Ecosystem Package Introduced Fixed