GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel adm1266 hwmon: device-supplied block length overflows the blackbox NVMEM buffer by 191 bytes

CVE-2026-64085Kernel, userspace & hypervisorcurated

Impact

adm1266_nvmem_read_blackbox() walks the 2048-byte dev_mem allocation in 64-byte strides, but the block transfer helper it calls will copy however many bytes the chip's length byte claims, up to 255. A device answering with more than 64 bytes on the trailing record writes up to 191 bytes past the allocation, and the driver's length check only runs after the copy. The trust boundary crossed here is hardware-to-host: the attacker is whatever sits on the board's PMBus/I2C segment - the sequencer's own firmware, or anything able to answer in its place - not a tenant. On a power-sequencer-equipped server the realistic outcome is kernel heap corruption and a node that has to be rebooted. Nodes whose boards do not carry an ADM1266, or that do not build CONFIG_SENSORS_ADM1266, have no exposure. This is one of three separate adm1266 fixes in this batch; the mechanisms and fixes differ, so they are listed separately.

Who can reach it

Requires a malicious or malfunctioning ADM1266 on the board's PMBus segment, plus a local read of the blackbox nvmem file - normally root-level access to sysfs on the host. Not reachable over the network and not reachable from a tenant pod without that sysfs path.

What to do

Pick up the fix in a stable kernel (commits linked in the record) and reboot each affected node, draining GPU workloads first. No vendor advisory or standalone fixed version is given beyond the upstream commits. Where the chip is not monitored, not building or not loading the adm1266 module removes the exposure without a kernel update.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.