CVE-2026-64135 in Linuxinfo

Summary

by MITRE • 07/19/2026

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

hwmon: (pmbus/adm1266) widen blackbox-info buffer to I2C_SMBUS_BLOCK_MAX

adm1266_nvmem_read_blackbox() declares a 5-byte stack buffer and passes it to i2c_smbus_read_block_data() to retrieve the 4-byte BLACKBOX_INFO response. i2c_smbus_read_block_data() does not honour caller buffer sizes -- it memcpy()s data.block[0] bytes from the
SMBus transaction (where data.block[0] is the length byte returned by
the slave device, up to I2C_SMBUS_BLOCK_MAX = 32):

memcpy(values, &data.block[1], data.block[0]);

If the device returns any block length above 5, the call overflows the caller's 5-byte stack buffer before the post-call

if (ret != 4) return -EIO;

check has a chance to reject the response.

Widen the local buffer to I2C_SMBUS_BLOCK_MAX so the helper has room for any well-formed SMBus block response, matching the convention used by the other i2c_smbus_read_block_data() callers in this driver.

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Analysis

by VulDB Data Team • 07/19/2026

This vulnerability resides within the Linux kernel's hardware monitoring subsystem, specifically affecting the pmbus/adm1266 driver which manages power management units. The issue manifests as a classic stack buffer overflow condition that occurs during the retrieval of blackbox information from power supply devices. The flaw stems from an inadequate buffer size declaration in the adm1266_nvmem_read_blackbox() function, which declares only a 5-byte stack buffer while attempting to read SMBus block data responses.

The technical implementation involves the i2c_smbus_read_block_data() helper function that does not respect the caller's buffer boundaries when processing SMBus transactions. This function retrieves data from the slave device where the first byte of the response contains the actual length of the data block, up to the maximum I2C_SMBUS_BLOCK_MAX value of 32 bytes. The problematic code performs a direct memory copy operation that does not validate whether the incoming data exceeds the allocated buffer space, specifically copying data.block[0] bytes starting from data.block[1] into the caller's 5-byte buffer.

The operational impact of this vulnerability represents a significant security risk within embedded systems and server environments where power management devices are critical components. When an adversary can manipulate the SMBus response from a target device to return more than 5 bytes of data, the system becomes susceptible to stack corruption that could lead to arbitrary code execution or system crashes. This type of buffer overflow vulnerability aligns with CWE-121 Stack-based Buffer Overflow, which specifically addresses conditions where insufficient bounds checking allows memory writes beyond allocated buffer boundaries.

The vulnerability demonstrates a failure in defensive programming practices and proper input validation within the kernel's I2C subsystem. The fix implemented involves expanding the local buffer size from 5 bytes to I2C_SMBUS_BLOCK_MAX (32 bytes) to accommodate any well-formed SMBus block response, thereby aligning with established patterns used by other callers within the same driver. This approach follows the principle of least privilege and defensive programming by ensuring adequate buffer space regardless of the actual data size returned by the device. The remediation strategy directly addresses ATT&CK technique T1068 for local privilege escalation through kernel exploits, as this vulnerability could potentially be leveraged to gain elevated system privileges.

The broader implications extend beyond immediate exploitation potential to include system stability concerns in production environments where power management devices operate continuously. This class of vulnerability commonly affects embedded systems and server hardware management controllers where I2c communication protocols are extensively used for monitoring and control functions, making it particularly relevant to enterprise infrastructure security and industrial control system protection. The fix reinforces proper resource management practices that should be applied consistently across all kernel subsystems handling external device communications to prevent similar buffer overflow conditions from occurring in other components.

Responsible

Linux

Reservation

07/19/2026

Disclosure

07/19/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Want to stay up to date on a daily basis?

Enable the mail alert feature now!