CVE-2026-64527

What it actually does

This is a Linux kernel flaw in the Hyper-V DRM/synthetic video receive path. The vulnerable code processes VMBus video packets before sufficiently validating the number of bytes actually received. For certain synthetic video message types, the driver could copy or interpret stale data left in a 16 KiB receive buffer as if it were part of the current response payload. In malformed packet cases, especially around completion responses and variable-length resolution responses, this can lead to disclosure of residual kernel/driver buffer contents to the consumer of the response path. The fix adds packet-size validation, validates type-specific payload lengths, bounds variable-length resolution arrays, rejects unknown or undersized messages, and only copies data after a successful bounded VMBus receive.

Why it matters to the business

The practical risk is information exposure from Linux virtual machines that use the Hyper-V synthetic video/DRM driver, primarily in scenarios where the Hyper-V host or VMBus message source is malicious, compromised, or outside the same trust boundary as the guest. For most organizations this is a moderate operational risk rather than an internet-exposed emergency because exploitation requires control over the virtualization channel, the EPSS score is low, there is no known CISA KEV listing, and no public exploit maturity is reported. The impact is more important for multi-tenant, confidential computing, regulated, or hostile-host threat models where guest memory confidentiality is a key requirement.

How an attack unfolds

An attacker with the ability to influence Hyper-V VMBus synthetic video messages sends a malformed or intentionally short packet to a Linux guest using the Hyper-V DRM/synthvid driver. The vulnerable receive callback reads the message type and dispatches to type-specific handling without first confirming that the packet contains the required pipe header, synthetic video header, and payload for that type. For completion-driving response messages, the driver may copy the receive buffer into an initialization buffer and wake a waiting consumer, which can then interpret leftover bytes from a previous packet as valid response data. For variable-length resolution responses, insufficient validation of the count-sized payload can similarly cause stale or unintended data to be treated as part of the response. In affected kernels, this creates an information-disclosure condition across malformed VMBus message handling. The patched behavior rejects undersized, oversized, inconsistent, or unknown packets and logs malformed-message cases instead of silently accepting them.

How to fix it

Upgrade the Linux kernel to a vendor build that includes the upstream fix for the Hyper-V DRM packet-size validation issue. Because no fixed package list was provided, use the latest security kernel from the relevant Linux distribution or platform image provider and confirm that it contains the drm/hyperv change that passes bytes_recvd into hyperv_receive_sub(), validates packet sizes before parsing, bounds SYNTHVID_RESOLUTION_RESPONSE resolution_count, and only copies data after successful vmbus_recvpacket() completion. Where immediate patching is not possible, reduce exposure by avoiding untrusted Hyper-V hosts, moving sensitive workloads away from affected Hyper-V guests, disabling or avoiding the Hyper-V synthetic video/DRM path where operationally feasible, and using hardened or confidential VM configurations where available. Reboot is typically required for kernel remediation to take effect.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, has been updated. Validate by checking the active kernel version against the distribution vendor advisory or kernel changelog for the drm/hyperv VMBus packet-size validation fix. On source-based or custom kernels, verify the Hyper-V DRM driver includes length-aware handling in the receive callback, rejects packets shorter than the required pipe and synthvid headers, validates type-specific payload lengths, bounds variable-length resolution responses, and gates copying on successful vmbus_recvpacket() return. After reboot, confirm the affected module or built-in driver is running from the patched kernel image. For exposure validation, inventory Linux guests running on Hyper-V or Azure-like Hyper-V virtualization and determine whether the hyperv_drm/hyperv_fb/synthetic video stack is present or loaded.

Typical attack path

1. Gain control of, compromise, or otherwise influence the Hyper-V host-side component that sends synthetic video VMBus messages to the Linux guest.
2. Identify that the guest is using the Hyper-V DRM/synthetic video driver path.
3. Send a crafted VMBus video packet with a valid-looking message type but an insufficient or inconsistent packet length.
4. Trigger one of the affected response-handling paths, such as version response, resolution response, VRAM location acknowledgement, or feature-change handling.
5. Cause the guest driver to process residual bytes from a previous receive buffer as part of the current response payload.
6. Use the exposed response data or side effects to infer sensitive guest kernel/driver memory contents or state.

How to detect it

Detection is difficult from inside the guest because exploitation occurs through the Hyper-V VMBus synthetic video channel and may not produce network indicators. Review guest kernel logs, dmesg, journald, and centralized syslog for DRM, Hyper-V, VMBus, synthvid, or hyperv_drm errors involving malformed, rejected, undersized, unknown, or invalid video packets. On patched systems, rejected malformed packets are expected to be reported through rate-limited DRM error logging; repeated entries may indicate probing or exploitation attempts. Review crash dumps or kernel warnings for stack traces involving hyperv_receive_sub(), vmbus_recvpacket(), Hyper-V DRM, or synthetic video handling. From the host side, correlate suspicious guest video-channel resets, VMBus errors, VM worker process anomalies, host hypervisor logs, and unauthorized virtualization-management activity. Because there are no public exploit artifacts or known threat actors reported for this issue, focus on behavioral evidence: malformed VMBus packet logs, unexpected Hyper-V video device errors, host compromise indicators, and unexplained guest kernel instability around Hyper-V DRM.

• hyperv_receive_sub
• vmbus_recvpacket
• hyperv_drm
• drm/hyperv
• synthvid
• SYNTHVID_VERSION_RESPONSE
• SYNTHVID_RESOLUTION_RESPONSE
• SYNTHVID_VRAM_LOCATION_ACK
• SYNTHVID_FEATURE_CHANGE
• malformed Hyper-V
• malformed VMBus
• invalid synthvid
• undersized packet
• unknown packet type

What your security team should do

• Prioritize patching Linux guests running on Hyper-V hosts where the host is outside the same trust boundary, shared with third parties, or part of a confidential-computing threat model.
• Track vendor kernel advisories and deploy the first available supported kernel containing the drm/hyperv packet validation fix; reboot affected systems after installation.
• Inventory virtual machines using Hyper-V synthetic video or Hyper-V DRM drivers and rank remediation by workload sensitivity.
• Review kernel logs for malformed Hyper-V video/VMBus packet errors after patching, as the fixed driver now reports rejected malformed packets via rate-limited DRM errors.
• If suspicious malformed VMBus activity is observed, investigate the Hyper-V host, virtualization management plane, and any recent host-level administrative access or compromise indicators.
• For high-assurance workloads, avoid relying on an untrusted host for guest confidentiality and consider isolation controls such as dedicated hosts, attestation-backed confidential VM features, or migration to trusted infrastructure.