Look up another CVE · open CVE-2026-63939 in the interactive tracker
CVE-2026-63939
KVM: SEV: Compute the correct max length of the in-GHCB scratch area
Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem arch/x86. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-63939 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 | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| 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
When setting the length of the GHCB scratch area, and the area is in the GHCB shared buffer, set the effective length of the scratch area to the max possible size given the start of the guest-provided pointer, and the end of the shared buffer. The code was "fine" when first introduced, as KVM doesn't consult the length of the buffer when emulating MMIO, because the passed in @len always specifies the *max* size required. But for PSC requests, the incoming @len is just the minimum length (to process the header), and KVM needs to know the full size of the scratch area to avoid buffer overflows (spoiler alert). Opportunistically rename @len => @min_len to better reflect its role.
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.
arch/x86/kvm/svm/sev.c
- What this is
- KERNEL VIRTUAL MACHINE FOR X86 (KVM/x86)MAINTAINERS section matched on arch/x86/kvm/*/ · kvm@vger.kernel.org · Supported
Show whether Debian builds this, per release
Not established. This site could not find the build rule for the affected file in the kernel trees Debian ships, so it has no answer about whether Debian compiles this code. Read that as unknown, never as absent.
- bookworm, trixie, forky, sid?
- ?
- not established - no Makefile entry for the affected file
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
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
Signals
- Published
- 2026-07-19 (3 months ago)source
- CVSS
- 9.3 critical
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.21%, higher than 10.7% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- arch/x86
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.11 | 6.12.93 | 6ca9400d3600 |
| 6.11 | 6.18.35 | 9f0a9e780f02 |
| 6.11 | 7.0.12 | 6644565527c4 |
| 6.11 | 7.1 | 5867d7e202e0 |
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
- Exploitation requires code running inside an SEV-SNP KVM guest that issues a PSC VMGEXIT via the GHCB protocol; the vulnerable path is reached through the local VM/hypercall interface (SVM_EXIT_VMGEXIT), not via any network-facing protocol.
- AC:LAttack complexity, low
- Once running in an SEV-SNP guest, the attacker fully controls the GHCB scratch GPA, PSC header indices, and entry contents, and can reliably trigger the bug without races or conditions outside their control.
- PR:NPrivileges required, none
- No host privileges are required; a cloud tenant or any party able to run a malicious SEV-SNP guest VM can reach this code without host root or CAP_SYS_ADMIN in the host init namespace.
- UI:NUser interaction, none
- Exploitation requires no action from a victim user; the malicious guest triggers the vulnerability autonomously during PSC VMGEXIT processing.
- S:CScope, changed
- The flaw is in KVM host-side handling of guest VMGEXIT requests and enables out-of-bounds kernel access that crosses the guest-to-hypervisor security boundary, consistent with a VM escape primitive.
- C:HConfidentiality impact, high
- The bug causes out-of-bounds reads of PSC entry structures beyond the computed scratch buffer length, which can leak kernel-mapped memory adjacent to the GHCB page.
- I:HIntegrity impact, high
- The kernel writes PSC completion data (entry cur_page and hdr.cur_entry) using attacker-controlled indices beyond the actual scratch buffer, enabling out-of-bounds writes exploitable for memory corruption.
- A:HAvailability impact, high
- Out-of-bounds access within the host's GHCB mapping can corrupt adjacent memory and trigger kernel oopses or panics, and repeated exploitation can deny service to the host and other tenants.