CVE-2026-64524

What it actually does

This flaw is in the Linux kernel Hyper-V DRM synthetic video driver. The driver parses a SYNTHVID_RESOLUTION_RESPONSE message containing a resolution_count value but did not properly cap that count to the fixed supported_resolution array size of 64 entries. A crafted response with resolution_count greater than 64 can cause the kernel parsing loop to walk past the end of the array, resulting in out-of-bounds memory access in kernel context. Depending on memory layout and build protections, the practical effect may include kernel memory disclosure, driver instability, or a kernel crash. The associated fallback logic bug can also leave maximum or preferred screen dimensions unset, causing framebuffer creation failures and display availability issues.

Why it matters to the business

Systems running Linux as Hyper-V guests may be exposed to guest kernel memory corruption or denial-of-service conditions through the Hyper-V synthetic video path. In practical business terms, exploitation could crash affected virtual machines, disrupt console or graphical access, and potentially expose sensitive kernel memory. The issue is not currently listed in CISA KEV, has no known public exploit maturity in the supplied data, and has a low EPSS score, so broad opportunistic exploitation appears unlikely at this time; however, affected virtualized workloads should still be patched during normal kernel maintenance because successful exploitation impacts confidentiality and availability at the kernel level.

How an attack unfolds

An attacker must be able to influence the Hyper-V synthetic video protocol messages consumed by the Linux guest kernel. The most realistic scenario is a malicious or compromised virtualization layer, host-side video service, or equivalent component capable of sending crafted SYNTHVID_RESOLUTION_RESPONSE data to the guest. During video capability negotiation, the attacker returns a response with resolution_count set above the supported maximum of 64. The vulnerable guest driver trusts the oversized count and iterates beyond the supported_resolution array boundary. That out-of-bounds access can corrupt or expose adjacent kernel memory or cause the guest kernel to fault. A separate but related fallback error can leave screen dimension limits unset after a failed WIN10 probe, causing framebuffer creation to fail and impairing graphical/display functionality.

How to fix it

Upgrade the Linux kernel to a version that includes the drm/hyperv fix validating resolution_count against SYNTHVID_MAX_RESOLUTION_COUNT and applying the corrected WIN8 fallback behavior. No exact fixed package versions were provided in the input, so remediation should be tracked through the relevant Linux distribution kernel advisories and upstream stable kernel updates. Where immediate patching is not possible, reduce exposure by limiting use of graphical console paths for affected Hyper-V guests where operationally feasible, restricting administrative access to Hyper-V hosts, hardening and monitoring the virtualization management plane, and avoiding untrusted or shared host environments for sensitive Linux guests.

How to confirm the fix worked

Confirm that the running kernel contains the drm/hyperv change that bounds resolution_count to the supported resolution array size and applies the post-probe WIN8 fallback when screen_width_max is zero. Practical validation methods include checking the installed kernel package against the distribution security advisory, reviewing the vendor changelog for the Hyper-V DRM fix, or inspecting source/build metadata for the resolution_count bounds check in the Hyper-V DRM driver. After patching, reboot into the fixed kernel and verify with uname -a and package-manager queries that the active kernel is the updated one. Functional validation should include confirming that Hyper-V guest display/framebuffer creation works normally and that kernel logs do not show hyperv_drm, framebuffer, or drm_internal_framebuffer_create errors during display initialization.

Typical attack path

1. Identify a Linux virtual machine using the Hyper-V synthetic video DRM driver.
2. Gain control of, compromise, or emulate the component that supplies Hyper-V synthetic video responses to the guest.
3. Trigger or wait for the guest to perform synthetic video resolution negotiation.
4. Send a crafted SYNTHVID_RESOLUTION_RESPONSE with resolution_count greater than 64.
5. Cause the guest kernel driver to parse beyond the fixed supported_resolution array.
6. Leverage the resulting kernel memory exposure or crash condition, or cause display/framebuffer failures through malformed negotiation behavior.

How to detect it

Retrospective detection is difficult because exploitation occurs inside kernel driver parsing and may not leave a clean application-level artifact. Review host and guest telemetry together. On Linux guests, examine kernel logs, journal entries, crash dumps, kdump/vmcore artifacts, and hypervisor-related logs for hyperv_drm, VMBus, DRM, framebuffer, KASAN, slab, page fault, general protection fault, kernel panic, or BUG/Oops messages occurring during display initialization, console resize, VM boot, resume, or graphics mode changes. Look for repeated framebuffer creation failures with -EINVAL, unexpected guest crashes tied to Hyper-V synthetic video activity, or abnormal display negotiation errors. On Hyper-V hosts, review management-plane and VM worker process logs around the same timestamps for unusual VM console/display operations, host agent changes, or crashes. If kernel sanitizers or crash dumps are available, prioritize evidence of out-of-bounds access in the Hyper-V DRM driver or parsing of SYNTHVID_RESOLUTION_RESPONSE messages with an excessive resolution count. There are no reliable network indicators for this issue because the vulnerable interaction occurs over the virtualization channel rather than a conventional network protocol.

• hyperv_drm
• SYNTHVID_RESOLUTION_RESPONSE
• resolution_count
• drm_internal_framebuffer_create
• -EINVAL
• general protection fault
• kernel BUG
• kernel panic
• Oops:
• KASAN: slab-out-of-bounds
• KASAN: out-of-bounds
• BUG: unable to handle page fault
• Hyper-V DRM
• VMBus
• hv_vmbus
• supported_resolution

What your security team should do

• Prioritize patching Linux kernels on Hyper-V guest systems, especially where VM availability or confidentiality is critical.
• Inventory Linux virtual machines that load the Hyper-V DRM or synthetic video driver and map them to their kernel package versions.
• Monitor Linux distribution advisories for the exact fixed kernel versions applicable to each deployed distribution and upgrade accordingly.
• Ensure affected systems are rebooted after kernel updates so the fixed kernel is actually running.
• Treat Hyper-V host compromise as a high-impact path: harden host administration, restrict management access, and monitor virtualization platform changes.
• For high-sensitivity workloads, avoid running affected unpatched guests on hosts that are shared with lower-trust tenants or administrators.
• Review kernel crash logs, display initialization errors, and Hyper-V VMBus/DRM messages for signs of abnormal synthetic video negotiation or instability.
• Because this is not KEV-listed and has low EPSS in the supplied data, handle as an important kernel maintenance issue rather than an active mass-exploitation emergency unless local threat intelligence indicates otherwise.