Linux kernel virtio-gpu: unvalidated EDID block offset lets a malicious backend read past a kernel buffer

Impact

virtio_get_edid_block() checks the read offset only against the device-supplied resp->size and never against the fixed-size resp->edid array, while the block index comes from the device-supplied extension count. A virtio-gpu backend that advertises a large size together with a high block count makes the guest kernel read well past the array into adjacent kernel memory, and the bytes come back out through the parsed EDID — an out-of-bounds read and information leak, with the record's vector also claiming an availability impact. Note the trust boundary this needs: in a conventional cloud the hypervisor already owns the guest, so this only buys an attacker something where the device model is outside the guest's trust boundary — a confidential VM, or a virtio-gpu backend running as a separate, less-trusted process. The record describes a malicious backend and does not name a confidential-computing scenario.

Who can reach it

Whoever controls the virtio-gpu device model on the host. Not reachable from inside the guest by a tenant, and not reachable over the network. No authentication concept applies — the backend is already the peer of the guest driver.

What to do

Patch the guest kernel to a stable release that also rejects reads whose end exceeds the edid array, then reboot the affected guests; conforming EDID responses are unaffected, so there is no functional regression to plan around. If a guest has no need for a virtio-gpu console, not attaching the device removes the exposure without a reboot cycle.

References