CVE-2026-64086

What it actually does

This is a local Linux kernel memory-safety flaw in the ADM1266 PMBus hardware-monitoring driver. The driver allocates a read buffer that is one byte too small for the maximum PMBus block response when Packet Error Checking is included. A max-length response can cause the I2C controller to write one byte past the end of the kernel buffer and can also cause a subsequent out-of-bounds read during PEC validation. In practical terms, this can corrupt adjacent kernel memory, crash the system, or potentially be shaped into local privilege escalation if an attacker can influence the PMBus/I2C response path and trigger the vulnerable driver operation.

Why it matters to the business

Systems using affected Linux kernels with ADM1266 PMBus hardware support may be exposed to local denial of service or possible privilege escalation. The risk is highest on servers, appliances, embedded platforms, or hardware-management environments where the ADM1266 driver is loaded and untrusted local users, containers, or management software can trigger hardware-monitoring reads. There is no indication that this is known to be exploited in the wild, it is not listed in CISA KEV, and the EPSS score is currently very low, so remediation should be prioritized based on whether the driver and hardware are present rather than treated as an internet-scale emergency.

How an attack unfolds

An attacker first needs local access to a system running an affected Linux kernel where the ADM1266 PMBus driver is present and reachable. The attacker then causes the driver to perform a PMBus block read from an ADM1266-compatible device or from a device path they can influence. If the response is crafted or induced to use the maximum block length and include a PEC byte, the kernel instructs the I2C controller to place more data into the driver buffer than it can hold. The extra byte lands past the end of the allocated buffer, and the following PEC check can read past the same buffer boundary. Depending on memory layout and kernel hardening, this may only generate a kernel warning or crash, but in a more favorable layout it may corrupt adjacent state and create a path to execute with kernel privileges.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the ADM1266 PMBus driver buffer sizing issue, or apply the vendor/backported kernel package containing the patch. Because no fixed package versions were provided, use the distribution or appliance vendor advisory as the source of truth and verify that the patch increases the ADM1266 read buffer to accommodate the length byte, maximum 255-byte payload, and PEC byte. If immediate patching is not possible, mitigate by disabling or unloading the adm1266 driver where it is not required, preventing automatic loading of the module, restricting access to I2C and hardware-monitoring interfaces to trusted administrators only, and reducing local shell/container access on systems with the affected hardware path.

How to confirm the fix worked

Confirm whether the system is exposed by checking for an affected kernel build and whether the ADM1266 driver is present or loaded. Validate remediation by confirming that the running kernel package includes the vendor fix or by inspecting the patched source/backport to ensure the ADM1266 read buffer is sized for ADM1266_PMBUS_BLOCK_MAX + 2. Operationally, verify that the updated kernel is actually booted, the old vulnerable kernel is not the active runtime, and the adm1266 module is either patched or unavailable if disabled as a mitigation. For defense-in-depth validation, review kernel logs after hardware-monitoring activity for the absence of KASAN, slab out-of-bounds, general protection fault, or kernel oops messages involving adm1266_pmbus_block_xfer or the PMBus stack.

Typical attack path

1. Gain local low-privileged access to a Linux system running an affected kernel.
2. Determine whether the ADM1266 PMBus driver is loaded or can be triggered through hardware-monitoring, I2C, or sysfs interfaces.
3. Trigger an ADM1266 PMBus block read operation.
4. Supply, emulate, or induce a maximum-length PMBus block response that includes the PEC byte.
5. Cause a one-byte out-of-bounds write and related out-of-bounds read in kernel context.
6. Use the resulting memory corruption to crash the host or attempt local privilege escalation.

How to detect it

Look for evidence of attempted or successful triggering in kernel and system logs rather than network telemetry, because exploitation is local and occurs inside the kernel driver path. Useful sources include dmesg, journald kernel logs, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore artifacts, kernel oops reports, audit logs for access to I2C device nodes, and command history or EDR telemetry showing interaction with hardware-monitoring interfaces. Focus on KASAN or kernel oops entries that reference adm1266_pmbus_block_xfer, adm1266, pmbus block transfers, I2C read failures, slab out-of-bounds, or crashes occurring immediately after hardware sensor reads. Also review whether untrusted users or containers accessed /dev/i2c-* or hardware-monitoring sysfs paths before a kernel fault. There are no known public exploit artifacts or threat actors associated with this issue based on the supplied data.

• adm1266_pmbus_block_xfer
• adm1266
• pmbus_block_xfer
• /sys/bus/i2c/drivers/adm1266
• /dev/i2c-
• BUG: KASAN: slab-out-of-bounds
• BUG: KASAN: out-of-bounds
• kernel BUG at drivers/hwmon/pmbus
• general protection fault
• BUG: unable to handle kernel paging request
• Oops:
• pmbus
• hwmon: (pmbus/adm1266)

What your security team should do

• Inventory Linux systems, appliances, and embedded platforms for loaded or available adm1266/PMBus hardware-monitoring support.
• Prioritize patching systems where ADM1266 hardware is present, the adm1266 driver is loaded, or local users/containers can interact with hardware-monitoring or I2C interfaces.
• Apply the vendor kernel update or backported fix, then reboot into the fixed kernel.
• If patching is delayed, disable or blacklist the adm1266 module where operationally safe.
• Restrict permissions on I2C device nodes and hardware-monitoring sysfs interfaces to trusted administrative users only.
• Monitor kernel logs for crashes, KASAN reports, or oops traces referencing adm1266_pmbus_block_xfer, adm1266, pmbus, or i2c activity.
• Treat unexpected kernel crashes on affected hardware as potentially security-relevant until logs and hardware-monitoring activity are reviewed.