GPU VulnDB

Database/NVIDIA / GPU stack

Linux amdgpu powerplay: malformed VBIOS VoltageObjectInfo table causes infinite loop or heap OOB read

UnscoredCVE-2026-93179NVIDIA / GPU stackcurated

Impact

The amdgpu power management code walked the VBIOS VoltageObjectInfo table without checking that each entry's usSize was at least the header size or that it stayed inside the table, so a malformed table could spin the cursor forever or read past the heap allocation. The practical exposure is narrow: the data comes from the card's own VBIOS, so triggering it means supplying a crafted or corrupted VBIOS - a flashed card, a tampered option ROM, or a passed-through virtual device whose ROM the guest controls. Where it does fire, it hangs or faults during driver init on an AMD accelerator node, which means the node comes up without GPUs and has to be taken out of the scheduling pool.

Who can reach it

Not reachable from a normal GPU tenant. Requires control over the VBIOS image the driver reads - physical or administrative access to flash the card, or a virtualization setup in which an untrusted guest supplies the device ROM to a host driver.

What to do

Pick up the stable kernel containing the fix (commits linked in the record) on AMD GPU nodes; a kernel update means drain and reboot each node. Given the attack path requires control of the VBIOS, this is reasonable to roll in with the next scheduled kernel maintenance rather than an emergency window. Treat option-ROM/VBIOS flashing as a privileged operation and verify card firmware on nodes that have been physically serviced or returned from RMA.

References

Related entries

All NVIDIA / GPU stack 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.