Skip to main content

Linux Kernel EUVDEUVD-2026-32441

| CVE-2026-46059 MEDIUM
2026-05-27 416baaa9-dc9f-4396-8d5f-8c081fb06d67 GHSA-fhch-vffp-hj8x
Linux Code Injection Red Hat Suse
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
vuln.today AI
4.7 MEDIUM

Multiple non-default co-conditions required (AMD hardware, nested=1, NRIPS disabled, soft interrupt injection, save/restore cycle) justify AC:H over the vendor-assigned AC:L.

3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
4.0 AV:L/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
MEDIUM
qualitative
Red Hat
5.5 LOW
qualitative

Primary rating from NVD.

CVSS VectorNVD

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

Lifecycle Timeline

6
Analysis Generated
Jun 16, 2026 - 03:30 vuln.today
CVSS changed
Jun 16, 2026 - 01:22 NVD
5.5 (MEDIUM)
CVSS changed
Jun 16, 2026 - 01:22 NVD
5.5 (MEDIUM)
Patch available
May 27, 2026 - 19:46 EUVD
CVE Published
May 27, 2026 - 14:17 nvd
MEDIUM 5.5
CVE Published
May 27, 2026 - 14:17 nvd
UNKNOWN (no severity yet)

DescriptionNVD

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

KVM: nSVM: Always use NextRIP as vmcb02's NextRIP after first L2 VMRUN

For guests with NRIPS disabled, L1 does not provide NextRIP when running an L2 with an injected soft interrupt, instead it advances the current RIP before running it. KVM uses the current RIP as the NextRIP in vmcb02 to emulate a CPU without NRIPS.

However, after L2 runs the first time, NextRIP will be updated by the CPU and/or KVM, and the current RIP is no longer the correct value to use in vmcb02. Hence, after save/restore, use the current RIP if and only if a nested run is pending, otherwise use NextRIP. Give soft_int_next_rip the same treatment, as it's the same logic, just for a narrower use case.

[sean: give soft_int_next_rip the same treatment]

AnalysisAI

Incorrect NextRIP state management in the Linux kernel's KVM nested SVM (nSVM) subsystem causes a denial-of-service condition affecting nested AMD virtualization environments from kernel 5.8 onward. After the first L2 VMRUN completes and NextRIP is updated by the CPU or KVM, a subsequent save/restore cycle incorrectly substitutes the stale current RIP in vmcb02, corrupting virtual machine control block state and crashing the nested guest or KVM subsystem. No active exploitation has been identified (not in CISA KEV, EPSS 0.02% at 4th percentile), and the vulnerability is strictly limited to AMD hosts with nested virtualization configured using NRIPS-disabled L1 guests with injected soft interrupts.

Technical ContextAI

The flaw resides in KVM's nested SVM implementation (nSVM), the Linux subsystem that allows an L1 hypervisor running inside a KVM VM to itself run L2 guests - so-called nested virtualization. The AMD NRIPS (Next RIP Saving) CPU feature, when enabled, causes the CPU to save the next instruction pointer on VM exits, simplifying interrupt re-injection. When an L1 hypervisor runs with NRIPS disabled, KVM must manually emulate this by copying the current RIP into vmcb02's NextRIP field before the VMRUN instruction. The bug is that after the first VMRUN, the CPU and/or KVM updates NextRIP to the correct post-instruction value, but the save/restore logic continues to unconditionally overwrite it with the (now stale) current RIP. The fix gates the RIP-as-NextRIP behavior on whether a fresh nested run is pending, and applies the same correction to the soft_int_next_rip path. The CPE is cpe:2.3:o:linux:linux_kernel. No CWE has been assigned, but the root cause is a conditional logic state-management error in vmcb02 preparation - the 'Code Injection' tag in the input data is inconsistent with the described behavior and CVSS impact metrics and should be disregarded.

RemediationAI

Update the Linux kernel to a vendor-released patched version: 6.18.27, 7.0.4, or 7.1-rc1. Fix commits are available upstream at https://git.kernel.org/stable/c/3428ed1529a1af4cce5aff6c5bd2fcc39ad726bb, https://git.kernel.org/stable/c/69fe1411a5ce678b4da6489b5d2282b4e1d13acf, and https://git.kernel.org/stable/c/8d397582f6b5e9fbcf09781c7c934b4910e94a50. For environments unable to patch immediately, disabling nested virtualization by loading the KVM-AMD module with 'nested=0' (e.g., 'options kvm_amd nested=0' in /etc/modprobe.d/) fully eliminates the attack surface with the trade-off of losing the ability to run hypervisors as guests - acceptable for most production workloads that do not use nested VMs. Alternatively, restricting KVM device access (via cgroup or permission controls) to trusted administrators reduces exposure to PR:L users who could trigger the condition. No confidentiality or integrity risk exists, so urgency is limited to environments where nested guest availability is operationally critical.

Same technique Code Injection

View all
CVE-2012-0158 HIGH POC
8.8
CVE-2014-6287 CRITICAL POC
9.8
CVE-2017-7494 CRITICAL POC
9.8
CVE-2025-24893 CRITICAL POC
9.8
CVE-2025-47812 CRITICAL POC
10.0
CVE-2013-3906 HIGH POC
7.8
CVE-2017-9822 HIGH POC
8.8
CVE-2018-1273 CRITICAL POC
9.8

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
openSUSE Tumbleweed Fixed
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

Share

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

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