Skip to main content

Linux Kernel KVM CVE-2026-46076

| EUVDEUVD-2026-32458 HIGH
2026-05-27 416baaa9-dc9f-4396-8d5f-8c081fb06d67 GHSA-gj33-hwgc-v3v8
Linux Information Disclosure
7.9
CVSS 3.1 · Vendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Share

Severity by source

Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67) PRIMARY
7.9 HIGH
AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:H
SUSE
HIGH
qualitative
Red Hat
7.0 MEDIUM
qualitative

Primary rating from Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67).

CVSS VectorVendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Changed
Confidentiality
Low
Integrity
Low
Availability
High

Lifecycle Timeline

5
Analysis Generated
May 30, 2026 - 11:44 vuln.today
CVSS changed
May 30, 2026 - 11:22 NVD
7.9 (HIGH)
Patch available
May 27, 2026 - 19:46 EUVD
CVE Published
May 27, 2026 - 14:17 nvd
UNKNOWN (no severity yet)
CVE Published
May 27, 2026 - 14:17 nvd
HIGH 7.9

DescriptionCVE.org

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

KVM: nSVM: Raise #UD if unhandled VMMCALL isn't intercepted by L1

Explicitly synthesize a #UD for VMMCALL if L2 is active, L1 does NOT want to intercept VMMCALL, nested_svm_l2_tlb_flush_enabled() is true, and the hypercall is something other than one of the supported Hyper-V hypercalls. When all of the above conditions are met, KVM will intercept VMMCALL but never forward it to L1, i.e. will let L2 make hypercalls as if it were L1.

The TLFS says a whole lot of nothing about this scenario, so go with the architectural behavior, which says that VMMCALL #UDs if it's not intercepted.

Opportunistically do a 2-for-1 stub trade by stub-ifying the new API instead of the helpers it uses. The last remaining "single" stub will soon be dropped as well.

[sean: rewrite changelog and comment, tag for stable, remove defunct stubs]

AnalysisAI

Privilege escalation and denial of service in the Linux kernel's nested SVM (nSVM) virtualization subsystem allows an L2 guest to issue VMMCALL hypercalls as if it were L1 when nested_svm_l2_tlb_flush_enabled() is true, L1 does not intercept VMMCALL, and the hypercall is not a supported Hyper-V call. The fix forces KVM to synthesize a #UD exception in this scenario, matching architectural behavior; no public exploit identified at time of analysis and EPSS exploitation probability is negligible (0.02%).

Technical ContextAI

The vulnerability resides in the KVM nested SVM (Secure Virtual Machine, AMD-V) code path that handles the VMMCALL instruction used by guests to invoke hypercalls. In a nested virtualization setup (L0 host running L1 hypervisor running L2 guest), KVM must decide whether to handle a VMMCALL itself or forward it to L1. When L1 had not requested VMMCALL interception but L0 KVM enabled L2 TLB flush hypercall handling via nested_svm_l2_tlb_flush_enabled(), KVM would still intercept VMMCALL yet fail to forward unsupported hypercalls back to L1, effectively letting L2 invoke L0 host hypercalls as if it were L1. The architectural specification requires an undefined-opcode (#UD) exception when VMMCALL is not intercepted, so the patch explicitly synthesizes #UD in this edge case. No CWE is assigned, but the root cause is improper privilege/scope handling at a virtualization boundary.

RemediationAI

Vendor-released patches are available in the Linux stable trees at versions 6.12.86, 6.18.27, 7.0.4, and mainline 7.1-rc1; upgrade affected AMD KVM hosts to one of these or a later stable release in the same series, available via https://git.kernel.org/stable/c/009c0f726abeaa67aad1d96b883bdce01d405ce2 and the companion commits 5fb4a5f361565f5b629d8a8fe5288ce8463c5727, 924d721fae95687acedbaf624a094ed0e8b67104, and c36991c6f8d2ab56ee67aff04e3c357f45cfc76c. Distribution kernels (RHEL, SUSE, Ubuntu, Debian) should pick up the backport - track your distro's security tracker for the rebuilt package version. If patching must be deferred, the practical compensating control is to disable nested virtualization on AMD hosts by setting the kvm_amd module parameter nested=0 (this breaks any L1 hypervisor workloads running on the host and is disruptive for nested-virt cloud tenants), or to restrict L2 guest workloads to trusted tenants so a malicious guest cannot reach the vulnerable VMMCALL path.

Same technique Information Disclosure

View all
CVE-2013-2251 CRITICAL POC
9.8
CVE-2017-5638 CRITICAL POC
9.8
CVE-2025-24813 CRITICAL POC
9.8
CVE-2015-1701 HIGH POC
7.8
CVE-2017-0147 HIGH POC
7.5
CVE-2014-6324 HIGH POC
8.8
CVE-2023-7028 CRITICAL POC
10.0
CVE-2017-0213 HIGH POC
7.3

Vendor StatusVendor

SUSE

Severity: High
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Performance Computing 15 SP7 Fixed

Share

CVE-2026-46076 vulnerability details – vuln.today
Back

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