Skip to main content

Linux Kernel EUVDEUVD-2026-45712

| CVE-2026-63939 CRITICAL
2026-07-19 Linux GHSA-94xr-m4g8-q6cc
Buffer Overflow Linux
9.3
CVSS 3.1 · Vendor: Linux
Share

Severity by source

Vendor (Linux) PRIMARY
9.3 CRITICAL
AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
vuln.today AI
7.8 HIGH

Attacker must control a SEV guest (PR:L, AV:L) and reliably groom host memory to weaponize the OOB write (AC:H); a successful guest-to-host escape crosses scope (S:C) with total host impact.

3.1 AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H
4.0 AV:L/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
SUSE
CRITICAL
qualitative
Red Hat
7.0 HIGH
qualitative

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

Attack Vector
Local
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jul 20, 2026 - 16:26 vuln.today
CVSS changed
Jul 20, 2026 - 15:22 NVD
9.3 (CRITICAL)
Patch available
Jul 19, 2026 - 17:19 EUVD
CVE Published
Jul 19, 2026 - 14:55 cve.org
CRITICAL 9.3
CVE Published
Jul 19, 2026 - 14:55 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

KVM: SEV: Compute the correct max length of the in-GHCB scratch area

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.

AnalysisAI

Host-side buffer overflow in the Linux kernel's KVM AMD SEV/SEV-ES support (arch/x86/kvm/svm/sev.c GHCB handling) lets a malicious or compromised confidential guest corrupt host memory by abusing Page State Change (PSC) requests. KVM miscomputes the maximum length of the in-GHCB scratch area, treating the guest-supplied @len as the buffer's full size when for PSC it is only a minimum, allowing a guest to drive writes past the shared GHCB buffer. Rated CVSS 9.3 for a scope-changed guest-to-host escape; no public exploit is identified at time of analysis and EPSS is low (0.22%), but a vendor patch is available across multiple stable branches.

Technical ContextAI

The flaw is in AMD SEV-ES/SEV-SNP guest handling inside KVM. Encrypted guests talk to the hypervisor through the Guest-Hypervisor Communication Block (GHCB), a shared page used for VMGEXIT-based emulation such as MMIO and Page State Change (PSC). KVM uses a 'scratch area' that may live inside the GHCB's shared buffer. Originally KVM only consulted the caller-provided @len as the *maximum* size needed (safe for MMIO emulation), but PSC requests pass @len as only the *minimum* length required to parse the header. Because KVM never bounded the scratch area to the space actually remaining between the guest-provided offset and the end of the shared buffer, a subsequent PSC operation can write beyond it. The fix computes the effective scratch length as the max size available from the start pointer to the end of the shared buffer and renames @len to @min_len. This is a classic out-of-bounds write / buffer overflow (CWE-787/CWE-120 class, though CWE is N/A in the feed) driven by insufficient validation of an attacker-influenced length. CPE identifies the product generically as cpe:2.3:a:linux:linux - the mainline kernel's KVM subsystem on AMD SEV-capable hosts.

RemediationAI

Vendor-released patch: update to a fixed stable kernel - 6.12.93, 6.18.35, 7.0.12, or the 7.1 line (or your distribution's backport containing stable commit 6ca9400d36005ffdca25f80186bea781c7e1dc4c or the sibling per-branch commits at git.kernel.org/stable/c/). Apply your distro's kernel update (RHEL/SUSE/Ubuntu/etc.) and reboot, then verify the running kernel includes the SEV GHCB scratch-length fix. Because exploitation requires a malicious SEV guest, the most effective compensating control until patching is to not run untrusted AMD SEV/SEV-ES/SNP confidential guests, or to restrict SEV guest creation to trusted tenants - trade-off: this disables confidential-computing capacity for those tenants. On hosts that do not use AMD SEV at all, exposure is effectively nil, so patch on the normal maintenance cycle. There is no meaningful in-guest workaround since the vulnerable logic runs in the host hypervisor; do not rely on guest-side controls. Reference advisory: https://nvd.nist.gov/vuln/detail/CVE-2026-63939.

Same technique Buffer Overflow

View all
CVE-2017-7269 CRITICAL POC
9.8
CVE-2015-5119 CRITICAL POC
9.8
CVE-2015-3113 CRITICAL POC
9.8
CVE-2011-2462 CRITICAL POC
9.8
CVE-2020-0796 CRITICAL POC
10.0
CVE-2019-11043 CRITICAL POC
9.8
CVE-2009-0927 HIGH POC
8.8
CVE-2012-1889 HIGH POC
8.8

Vendor StatusVendor

SUSE

Severity: Critical
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 16.0 Affected

Share

EUVD-2026-45712 vulnerability details – vuln.today
Back

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy