CVE-2026-64524: Linux Kernel Privilege Escalation Flaw

CVE-2026-64524 Overview

CVE-2026-64524 is a Linux kernel vulnerability in the drm/hyperv graphics driver used by Hyper-V guests. The flaw resides in the handling of SYNTHVID_RESOLUTION_RESPONSE messages, where an untrusted resolution_count value is not validated against the size of the supported_resolution[SYNTHVID_MAX_RESOLUTION_COUNT] array. A message with resolution_count > 64 causes the parse loop to walk past the fixed-size array, producing an out-of-bounds access. The upstream fix also repairs a WIN8 fallback gap that left screen_*_max and preferred_* fields unpopulated when the WIN10 resolution probe failed.

Critical Impact
A malicious or malfunctioning Hyper-V host component can trigger an out-of-bounds read in a Linux guest kernel, resulting in memory disclosure or denial of service with high confidentiality and availability impact.

Affected Products

Linux kernel with the drm/hyperv (Hyper-V synthetic video) driver enabled
Linux guests running on Microsoft Hyper-V hypervisor
Stable kernel branches receiving backport commits 13d33b9, 1fb565b, 8a114b2, 96f7de3, 9c698b2, a321c90, and bc57375

Discovery Timeline

2026-07-25 - CVE-2026-64524 published to NVD
2026-07-27 - Last updated in NVD database

Technical Details for CVE-2026-64524

Vulnerability Analysis

The drm/hyperv driver receives resolution data from the Hyper-V host through a synthetic video VMBus channel. When the host sends a SYNTHVID_RESOLUTION_RESPONSE, the guest driver iterates resolution_count entries and copies them into a fixed-size array supported_resolution[SYNTHVID_MAX_RESOLUTION_COUNT], which holds 64 entries. The driver checked only that resolution_count was non-zero before entering the parse loop. Any value greater than 64 causes the loop to read attacker-supplied bytes into memory beyond the array. This is an out-of-bounds write into adjacent kernel structures and an out-of-bounds read of the message buffer, classifiable under [CWE-787] and [CWE-125].

Root Cause

The root cause is missing upper-bound validation on a length field received from an untrusted communication peer. The existing zero-check on resolution_count was not folded together with a bound against SYNTHVID_MAX_RESOLUTION_COUNT. A secondary defect exists in hyperv_connect_vsp(): when the WIN10 probe fails, hv->screen_*_max and preferred_* remain zero, which sets mode_config.max_width and max_height to zero. This causes drm_internal_framebuffer_create() to reject every userspace framebuffer with -EINVAL. The pre-WIN10 branch had the same gap for preferred_width and preferred_height.

Attack Vector

The attack requires local presence, but the local vector here refers to the VMBus channel between the Hyper-V host and the guest kernel. A compromised host, a malicious hypervisor-side component, or a fault-injection scenario against the synthetic video protocol can deliver a crafted SYNTHVID_RESOLUTION_RESPONSE frame. The guest driver then reads past its resolution array during message parsing. The fix bounds resolution_count against the array size and consolidates the WIN8 fallback so both probe paths converge on safe default screen dimensions.

See the upstream patches at Kernel Git Commit 8a114b2 and Kernel Git Commit 9c698b2 for the technical fix details.

Detection Methods for CVE-2026-64524

Indicators of Compromise

Kernel oops, general protection fault, or KASAN out-of-bounds report referencing hyperv_drm or synthvid symbols
Unexpected DRM framebuffer creation failures returning -EINVAL from drm_internal_framebuffer_create() on Hyper-V guests
Guest crash or hang shortly after Hyper-V synthetic display negotiation

Detection Strategies

Enable Kernel Address Sanitizer (KASAN) on test kernels to catch out-of-bounds accesses in the hyperv_drm module during resolution negotiation
Monitor dmesg for warnings originating from drm/hyperv code paths after VM boot or display resize events
Compare running kernel commit against the fix commits 8a114b2, 9c698b2, 13d33b9, 1fb565b, 96f7de3, a321c90, and bc57375 on affected stable branches

Monitoring Recommendations

Collect kernel logs from Hyper-V Linux guests centrally and alert on hyperv_drm, synthvid, or DRM subsystem faults
Track kernel version inventory across virtualized Linux estates to identify hosts pending the drm/hyperv fix
Correlate guest crash events with Hyper-V host maintenance or migration windows to detect anomalous synthetic video traffic

How to Mitigate CVE-2026-64524

Immediate Actions Required

Apply the stable kernel update containing commit 8a114b25b5521eae451b13bce98ae978624962e5 or the equivalent backport for your distribution
Prioritize patching Linux guests running on Hyper-V, including Azure Linux VMs, where the hyperv_drm module is loaded
Restrict administrative access to the Hyper-V host and management plane so untrusted operators cannot influence synthetic video traffic

Patch Information

The Linux kernel maintainers merged the fix across multiple stable branches. Relevant commits include Kernel Git Commit 8a114b2, Kernel Git Commit 13d33b9, Kernel Git Commit 1fb565b, Kernel Git Commit 96f7de3, Kernel Git Commit 9c698b2, Kernel Git Commit a321c90, and Kernel Git Commit bc57375. The patch bounds resolution_count against SYNTHVID_MAX_RESOLUTION_COUNT and unifies the WIN8 fallback for screen_*_max and preferred_*.

Workarounds

Where display output is not needed, unload or blacklist the hyperv_drm module on affected guests until a patched kernel is deployed
Use text-mode or serial console access for management to remove reliance on the vulnerable synthetic video path
Ensure Hyper-V hosts are fully patched and hardened so hostile input to the synthetic video channel cannot originate from tenant workloads

bash

# Blacklist the hyperv_drm module on affected Linux guests until patched
echo 'blacklist hyperv_drm' | sudo tee /etc/modprobe.d/blacklist-hyperv-drm.conf
sudo update-initramfs -u
sudo reboot