Look up another CVE · open CVE-2026-64524 in the interactive tracker
CVE-2026-64524
drm/hyperv: validate resolution_count and fix WIN8 fallback
Published 2026-07-25 (3 months ago) by the Linux kernel CNA. Subsystem drivers/gpu. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-64524 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixed | 6.1.176-1 | Update the kernel and reboot. Fixed in 6.1.176-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.94-1 | Update the kernel and reboot. Fixed in 6.12.94-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
A SYNTHVID_RESOLUTION_RESPONSE with resolution_count > 64 walks past the supported_resolution[SYNTHVID_MAX_RESOLUTION_COUNT] array in the parse loop. Bound resolution_count against the array size, folded into the existing zero-check. When the WIN10 resolution probe fails, the caller in hyperv_connect_vsp() left hv->screen_*_max / preferred_* unpopulated, which sets mode_config.max_width / max_height to 0 and makes drm_internal_framebuffer_create() reject every userspace framebuffer with -EINVAL. The pre-WIN10 branch had the same gap for preferred_width / preferred_height. Use a single post-probe fallback guarded by screen_width_max == 0 so both paths converge on the WIN8 defaults.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/gpu/drm/hyperv/hyperv_drm_proto.c
- What this is
- DRM DRIVER FOR HYPERV SYNTHETIC VIDEO DEVICEMAINTAINERS section matched on drivers/gpu/drm/hyperv · linux-hyperv@vger.kernel.org · Maintained
- Kernel module
- hyperv_drm
Check it on the machine
grep -w CONFIG_DRM_HYPERV /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w hyperv_drmPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le
- trixieMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- M
- a module where it is built at all; some flavours do not build it
- Build switch
- CONFIG_DRM_HYPERV
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-07-25 (3 months ago)source
- CVSS
- 7.7 high
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.14%, higher than 3.1% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/gpu
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.14 | 5.15.210 | 96f7de3172d4 |
| 5.14 | 6.1.176 | bc573752f3da |
| 5.14 | 6.6.143 | 1fb565b77b8f |
| 5.14 | 6.12.93 | a321c908f2ee |
| 5.14 | 6.18.35 | 9c698b2c43c2 |
| 5.14 | 7.0.12 | 8a114b25b552 |
| 5.14 | 7.1 | 13d33b9ef670 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The malicious resolution response must originate from the local Hyper-V synthetic-video backend over VMBus; it is not reachable through a network protocol or guest userspace ioctl.
- AC:LAttack complexity, low
- The backend can deterministically trigger the flaw by returning a resolution_count from 65 through 255 during the normal WIN10+ probe or resume exchange, without a race or unpredictable condition.
- PR:NPrivileges required, none
- The guest accepts the VMBus response without authentication, capability checks, or guest credentials; a malicious or compromised backend requires no privileges within the vulnerable guest.
- UI:NUser interaction, none
- The response is processed automatically during device probing or resume, without any victim action.
- S:UScope, unchanged
- The vulnerable parser and the affected DRM and kernel resources are within the same guest-kernel security authority; this does not produce a guest-to-host escape.
- C:HConfidentiality impact, high
- A count of 255 causes 191 additional four-byte entries to be read beyond the declared array, substantially exceeding a small bounded disclosure and allowing out-of-bounds kernel data to influence observable display state.
- I:NIntegrity impact, none
- The invalid accesses are reads, and their results are written only to the intended resolution fields; no out-of-bounds write, use-after-free, or control-flow corruption was found.
- A:HAvailability impact, high
- Bounds-instrumented hardened kernels can oops when index 64 is reached, while a failed or malformed resolution probe can leave zero maximum dimensions and make every userspace framebuffer creation fail.