Skip to main content

Linux Kernel EUVDEUVD-2026-49019

| CVE-2026-64307 MEDIUM
2026-07-25 Linux GHSA-wv9v-6465-83fw
Denial Of Service Linux 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

AC:H reflects the multi-precondition requirement (prior failed SNP init + AMD hardware + active KVM guests); no confidentiality or integrity impact.

3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
4.0 AV:L/AC:H/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 MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

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

Lifecycle Timeline

5
Analysis Generated
Sep 04, 2026 - 13:24 vuln.today
CVSS changed
Sep 04, 2026 - 13:22 NVD
5.5 (MEDIUM)
Patch available
Jul 25, 2026 - 11:18 EUVD
CVE Published
Jul 25, 2026 - 08:49 cve.org
UNKNOWN (no severity yet)
CVE Published
Jul 25, 2026 - 08:49 nvd
MEDIUM 5.5

DescriptionNVD

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

crypto: ccp - Do not initialize SNP for ioctl(SNP_CONFIG)

Sashiko notes:

> if SEV initialization fails and KVM is actively running normal VMs, could a > userspace process trigger this code path via /dev/sev ioctls (e.g., > SEV_PDH_GEN) and zero out MSR_VM_HSAVE_PA globally? Would the next VMRUN > execution for an active VM trigger a general protection fault and crash the > host?

Refuse to re-try initialization if SNP is not already initialized for SNP_CONFIG.

This is technically an ABI break: before if SNP initialization failed it could be transparently retriggered by this ioctl, and if no VMs were running, everything worked fine. Hopefully this is enough of a corner case that nobody will notice, but someone does, there are a few options:

  • do something like symbol_get() for kvm and refuse to initialize if KVM is

loaded

  • check each cpu's HSAVE_PA for non-zero data before re-initializing
  • once initialization has failed, continue to refuse to initialize until

the ccp module is unloaded

AnalysisAI

Host crash vulnerability in the Linux kernel's AMD SEV/SNP subsystem allows a local low-privileged user to take down a virtualization host by triggering SNP re-initialization via the /dev/sev SNP_CONFIG ioctl when SNP has previously failed to initialize. When re-initialization executes while KVM guests are running, it zeroes MSR_VM_HSAVE_PA globally across all CPUs; the next VMRUN instruction on any active guest then raises a General Protection Fault, crashing the host kernel and terminating all hosted VMs. No public exploit identified at time of analysis; EPSS is 0.22% at the 13th percentile, consistent with low opportunistic exploitation probability.

Technical ContextAI

The crypto/ccp driver (AMD Cryptographic Co-Processor) exposes AMD SEV (Secure Encrypted Virtualization) and SNP (Secure Nested Paging) management through the /dev/sev character device. MSR_VM_HSAVE_PA is a per-CPU AMD architecture register that stores the host-save area physical address required for hypervisor state preservation across VMRUN/VMEXIT transitions. The affected code path in the SNP_CONFIG ioctl handler lacked a guard to skip re-initialization when SNP was not already in an initialized state. If SNP initialization had previously failed and then a userspace caller triggered SNP_CONFIG, the initialization routine would overwrite MSR_VM_HSAVE_PA with zero on all CPUs, rendering the hypervisor unable to safely execute VMRUN. The CWE is listed as N/A; the closest applicable class is CWE-665 (Improper Initialization) or CWE-362 (TOCTOU-adjacent state race). Affected CPE: cpe:2.3:a:linux:linux across multiple stable branches.

RemediationAI

Update the Linux kernel to a patched stable release: 6.12.97, 6.18.39, or 7.1.4 (or later). The upstream fix commits are available at https://git.kernel.org/stable/c/345a6e869b33687e9268044bcaeeefd7c61da675, https://git.kernel.org/stable/c/441ea32cf2755a0dc593557056b00b7caa0651f5, https://git.kernel.org/stable/c/20f548cdac94860a164e5ebba4f7e4a01051cb06, and https://git.kernel.org/stable/c/08f0e65e784c4b20e6e620dd4f68d8636073a3d2. If immediate patching is not possible, restrict access to /dev/sev to root only (remove group read/write permissions and remove non-root users from any kvm or sev group that grants device access) - this trades off operational flexibility for attack surface reduction. Alternatively, unload the ccp kernel module on systems that do not require SEV-SNP functionality, accepting that AMD crypto offload and SEV features will be unavailable. No other vendor advisory beyond the kernel commit logs has been identified.

Same technique Denial Of Service

View all
CVE-2015-5119 CRITICAL POC
9.8
CVE-2011-2462 CRITICAL POC
9.8
CVE-2011-0611 HIGH POC
8.8
CVE-2012-1889 HIGH POC
8.8
CVE-2012-0507 CRITICAL POC
9.8
CVE-2014-1761 HIGH POC
7.8
CVE-2015-5122 CRITICAL POC
9.8
CVE-2011-0609 HIGH POC
7.8

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
openSUSE Tumbleweed Fixed
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected

Share

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

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