CVE-2026-64135

What it actually does

This flaw is a stack-based buffer overflow in the Linux kernel ADM1266 PMBus hardware-monitoring driver. The driver allocates a 5-byte stack buffer for a BLACKBOX_INFO SMBus block read, but the SMBus helper can copy up to 32 bytes based on the length returned by the device. A malicious, faulty, or compromised ADM1266-compatible I2C/SMBus device that returns a block length greater than 5 can overwrite adjacent kernel stack memory before the driver validates the response length. Depending on kernel configuration, stack layout, and exploitability constraints, this can cause a kernel crash, memory corruption, denial of service, or potentially kernel-mode code execution. Exploitation requires access to, control of, or emulation of the affected I2C/SMBus device path and the vulnerable driver being present and exercised.

Why it matters to the business

The most likely operational impact is instability or outage of Linux systems that use the affected ADM1266 PMBus hardware-monitoring driver, especially embedded, appliance, industrial, server-management, or hardware-control platforms connected to ADM1266 devices. Because exploitation depends on a local hardware/bus interaction rather than a typical remote network request, broad internet-scale exploitation is unlikely; however, systems where attackers can modify firmware, attach rogue bus devices, compromise management controllers, or influence I2C/SMBus responses could face host crashes or deeper kernel compromise. The issue is not listed in CISA KEV, has no known ransomware association, and currently has very low EPSS, so remediation should be prioritized based on exposure to affected hardware and threat models involving physical, supply-chain, firmware, or management-controller compromise.

How an attack unfolds

An attacker first needs a path to influence the SMBus response consumed by the Linux ADM1266 PMBus driver. This could involve physical access to the bus, a malicious replacement or counterfeit device, compromised peripheral firmware, a compromised baseboard or management component, or a lab/embedded scenario where the attacker can emulate the ADM1266 device. When the kernel driver calls adm1266_nvmem_read_blackbox(), it expects a 4-byte BLACKBOX_INFO response and provides a 5-byte stack buffer to i2c_smbus_read_block_data(). The SMBus transaction includes a length byte controlled by the responding device. If that length is greater than 5, the helper copies that many bytes into the smaller stack buffer, corrupting adjacent kernel stack memory before the driver checks whether the return length equals 4. In a simple attack, this corruption causes a kernel oops, panic, watchdog reset, or service outage. In a more advanced and target-specific attack, the overflow may be shaped to alter kernel control data and attempt privilege escalation or arbitrary kernel code execution, though practical exploitation depends heavily on architecture, compiler hardening, stack protections, and precise kernel build details.

How to fix it

Update to a Linux kernel version or vendor kernel package that includes the ADM1266 PMBus driver fix widening the BLACKBOX_INFO local buffer to I2C_SMBUS_BLOCK_MAX. Where distribution advisories are available, apply the fixed kernel package from the operating-system or appliance vendor rather than manually patching production kernels. If immediate patching is not possible, reduce exposure by disabling or blacklisting the adm1266 driver where the hardware-monitoring functionality is not required, restricting access to I2C/SMBus device nodes and hardware-management interfaces, preventing untrusted peripheral attachment, and validating firmware and hardware supply-chain integrity for systems using ADM1266-compatible devices. On embedded or appliance platforms, coordinate with the platform vendor for firmware or kernel image updates that include the upstream fix.

How to confirm the fix worked

Confirm the running kernel includes the fix from the relevant vendor advisory or upstream stable branch, not merely that source packages have been updated. Validate with package manager metadata, kernel build changelogs, or source inspection showing adm1266_nvmem_read_blackbox() uses a buffer sized to I2C_SMBUS_BLOCK_MAX for SMBus block reads. Reboot into the updated kernel and verify the active kernel version with standard OS tooling. Check whether the vulnerable driver is present or loaded using module inventory and kernel configuration review. If mitigation relies on disabling the driver, confirm the adm1266 module cannot be loaded and that no ADM1266 hwmon/nvmem sysfs entries are exposed. In test environments with appropriate hardware simulation, confirm oversized SMBus block responses no longer corrupt the kernel stack and are safely rejected by the post-read length validation.

Typical attack path

1. Identify a Linux system using the ADM1266 PMBus hardware-monitoring driver or otherwise exposing an ADM1266-compatible I2C/SMBus device to the kernel.
2. Gain the ability to control, emulate, replace, or tamper with the ADM1266/PMBus device or the I2C/SMBus communication path.
3. Trigger the driver's ADM1266 blackbox information read path, such as through hardware-monitoring, nvmem, sysfs, diagnostics, or driver initialization behavior.
4. Return an SMBus block response with a length greater than the driver's 5-byte stack buffer, up to the SMBus maximum block length.
5. Cause the kernel helper to copy the oversized response into the undersized stack buffer before validation occurs.
6. Leverage the resulting kernel stack corruption to crash the system or, where feasible, attempt kernel-level control-flow manipulation.

How to detect it

Retrospective detection should focus on kernel and system logs, crash dumps, watchdog events, and hardware-management telemetry because exploitation occurs through a local hardware bus interaction rather than a network signature. Review journald, syslog, dmesg, kdump/vmcore data, pstore/ramoops, appliance crash logs, BMC or management-controller event logs, and hardware-monitoring service logs for kernel oopses, panics, stack-smashing detections, or memory-corruption traces involving the adm1266 PMBus driver, pmbus, i2c, nvmem reads, or i2c_smbus_read_block_data. Look for unexpected reboots or watchdog resets temporally associated with hardware-monitoring reads, sensor polling, platform diagnostics, device initialization, or access to hwmon/nvmem sysfs entries. Because no public exploitation is reported and there are no known threat-actor campaigns for this issue, absence of these artifacts does not prove safety, but their presence should trigger kernel crash analysis and investigation of physical, firmware, supply-chain, or management-controller tampering.

• adm1266
• pmbus
• i2c_smbus_read_block_data
• adm1266_nvmem_read_blackbox
• BLACKBOX_INFO
• hwmon: (pmbus/adm1266)
• Kernel panic
• kernel BUG
• Oops:
• general protection fault
• stack smashing detected
• Kernel stack is corrupted
• watchdog: BUG: soft lockup
• watchdog: Watchdog detected hard LOCKUP
• /sys/class/hwmon/
• /sys/bus/i2c/drivers/adm1266
• /sys/bus/i2c/drivers/pmbus
• adm1266.ko
• pmbus.ko

What your security team should do

• Inventory Linux systems, appliances, and embedded platforms that use ADM1266 PMBus hardware-monitoring functionality or load the adm1266/pmbus drivers.
• Prioritize patching systems where attackers may have physical access, peripheral access, firmware-update capability, management-controller access, or other ability to influence I2C/SMBus devices.
• Apply vendor-provided kernel or firmware updates that include the ADM1266 buffer-size fix, then reboot into the updated kernel.
• If the driver is unnecessary, blacklist or remove the adm1266 driver and restrict access to I2C device interfaces as a compensating control.
• Review hardware supply-chain, firmware integrity, and management-controller security for platforms where PMBus telemetry devices are part of the trust boundary.
• Monitor for kernel crashes, stack-smashing reports, oops traces, or unexpected reboots involving adm1266, pmbus, i2c_smbus_read_block_data, or adm1266_nvmem_read_blackbox.
• Treat confirmed anomalous SMBus behavior on sensitive systems as a potential firmware, hardware, or physical-access incident, not only as a software crash.