CVE-2026-64085 in Linux
Summary
by MITRE • 07/19/2026
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (pmbus/adm1266) bounce blackbox records through a protocol-sized buffer
adm1266_pmbus_block_xfer() copies the device-supplied block payload into the caller-provided buffer using the device-supplied length:
memcpy(data_r, &msgs[1].buf[1], msgs[1].buf[0]);
The helper does not know how large data_r is and trusts the device to return at most one record's worth of bytes. adm1266_nvmem_read_blackbox() violates that contract: it advances read_buff inside data->dev_mem in ADM1266_BLACKBOX_SIZE (64-byte) strides while the helper is willing to write up to ADM1266_PMBUS_BLOCK_MAX (255) bytes. A device that returns more than 64 bytes on the trailing record (read_buff offset 1984 in the 2048-byte dev_mem allocation) overflows dev_mem by up to 191 bytes before the post-call
if (ret != ADM1266_BLACKBOX_SIZE) return -EIO;
can reject the response.
Contain the fix in the caller without changing the helper signature: read each record into a 255-byte local bounce buffer that matches the helper's maximum output, validate the returned length, and only then copy exactly ADM1266_BLACKBOX_SIZE bytes into the dev_mem slot.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 07/19/2026
The vulnerability exists within the Linux kernel's hardware monitoring subsystem specifically in the pmbus/adm1266 driver implementation. This issue stems from a buffer overflow condition that occurs during the handling of blackbox records through protocol-sized buffers. The core problem manifests in the adm1266_pmbus_block_xfer() function which performs a memcpy operation without proper bounds checking against the caller-provided buffer size. The function blindly trusts device-supplied length values and copies data directly into the target buffer using the formula memcpy(data_r, &msgs[1].buf[1], msgs[1].buf[0]) where data_r represents the caller's buffer and msgs[1].buf[0] contains the device-provided length value. This design pattern creates a fundamental mismatch between expected buffer sizes and actual implementation constraints.
The operational impact becomes critical when examining how adm1266_nvmem_read_blackbox() function violates the established contract by advancing through read_buff in 64-byte strides while the helper function remains unconstrained in its output capacity. The maximum block size allowed by the PMBUS protocol is 255 bytes as defined by ADM1266_PMBUS_BLOCK_MAX, whereas the blackbox data structure operates on 64-byte records within a 2048-byte dev_mem allocation. When a device returns more than 64 bytes during the final record processing phase, specifically at offset 1984 in the allocated memory, the system overflows the dev_mem buffer by up to 191 bytes before the validation check can occur. This overflow represents a classic buffer overrun vulnerability that could potentially allow arbitrary code execution or system instability.
This vulnerability maps directly to CWE-121 heap-based buffer overflow and aligns with ATT&CK technique T1068 which targets privilege escalation through software vulnerabilities. The flaw demonstrates poor input validation and memory management practices where the kernel driver fails to enforce proper bounds checking between different data structures. The fix strategy requires implementing a containment approach that maintains backward compatibility while addressing the root cause. Rather than modifying the helper function signature, the solution involves creating a local 255-byte bounce buffer within the caller's scope to match the maximum output capacity of the helper function. This approach ensures that each record is first read into the bounded local buffer, validated against expected length parameters, and only then selectively copied into the target dev_mem slot using exactly ADM1266_BLACKBOX_SIZE bytes. The validation step occurs before any copying operation, effectively preventing the overflow condition while maintaining the integrity of the existing API contract. This mitigation strategy follows established security principles for preventing buffer overflows by implementing proper bounds checking and defensive programming practices.