CVE-2026-68255
NoneCVSS
—
EPSS
0.2%
Published
Aug 10, 2026
CISA due date
—
Cloudanix analysis
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
- Gain control of the virtio-gpu backend device
- Craft EDID response with oversized size and high extension count
- Trigger guest EDID block retrieval via display initialization or hotplug
- 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 |
|---|