Cloudanix VulnDB

CVE-2026-68255

None

CVSS

—

EPSS

0.2%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A bug in handling display information from virtual graphics cards could let a malicious graphics device peek at private areas of the system's core memory.

Exploitation
Local Privilege
Attacker needs
High Privilege
Complexity
Theoretical
Impact
Data Exposure
Component
OS kernel
Class
Information Disclosure
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Out-of-bounds read in virtio_get_edid_block() where the device-controlled resp->size and extension count are not validated against the fixed-size resp->edid array, allowing reads past the array boundary into adjacent kernel memory that is then exposed via parsed EDID data.

Why it matters to the business

In virtualized environments using virtio-gpu, a malicious or compromised backend can leak kernel memory contents, potentially aiding further attacks or exposing sensitive data without direct code execution.

How an attack unfolds

An attacker controlling the virtio-gpu backend supplies a response advertising both a large size and high block count; the guest driver then performs EDID block reads that exceed the array bounds, copying kernel memory into the response that is surfaced to user space.

How to fix it

Apply the upstream kernel patch that adds explicit bounds checks ensuring every EDID read stays within the resp->edid array; rebuild and deploy updated kernels on all affected systems using virtio-gpu.

How to confirm the fix worked

Confirm the fix by inspecting the virtio_get_edid_block function for the added end-of-read check against the edid array size, and test with a backend that advertises oversized responses to verify they are rejected.

Typical attack path

  1. Gain control of the virtio-gpu backend device
  2. Craft EDID response with oversized size and high extension count
  3. Trigger guest EDID block retrieval via display initialization or hotplug
  4. Receive and parse leaked kernel memory from the oversized response

How to detect it

Examine virtio-gpu and drm logs for EDID responses reporting extension counts or sizes that exceed normal display limits; post-exploitation detection is limited because the flaw only leaks data without leaving persistent artifacts.

What your security team should do

  • Prioritize kernel updates for all hosts and guests using virtio-gpu in production
  • Review virtualization stack configurations to limit untrusted GPU backends
  • Monitor kernel update channels for the specific virtio drm fix

The record

In the Linux kernel, the following vulnerability has been resolved: drm/virtio: bound EDID block reads to the response buffer virtio_get_edid_block() validates the read offset only against the device-supplied resp->size field, never against the fixed-size resp->edid array. The EDID block index is driven by the device-supplied extension count, so a malicious virtio-gpu backend can advertise a large size together with a high block count and read far past the array into adjacent kernel memory, which is then surfaced in the parsed EDID (an out-of-bounds read / info leak). Also reject any read whose end exceeds the size of the edid array. Conforming EDID responses stay within the array and are unaffected.

Affected packages

Ecosystem Package Introduced Fixed