From mboxrd@z Thu Jan 1 00:00:00 1970 From: AL-KERNEL To: kernel-cve@kernelcve.org Subject: [CVE-2026-64308][MODERATE REGULAR] crypto: ccp - Do not initialize SNP for ioctl(SNP_VLEK_LOAD) Date: Sat, 25 Jul 2026 13:29:31 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AL-KERNEL-CVE: CVE-2026-64308 X-AL-KERNEL-Priority: MODERATE REGULAR X-AL-KERNEL-Severity: MODERATE REGULAR X-AL-KERNEL-Base-Severity: MODERATE X-AL-KERNEL-KPANIC: NO X-AL-KERNEL-ActionableScore: 4 X-AL-KERNEL-ActionableScore-Lower: 2 X-AL-KERNEL-Commit: 61cf5eef20657bff9ca235fe938a99ce5ff65c06 List-Id: CVE: CVE-2026-64308 Priority: MODERATE REGULAR AL-KERNEL base severity: MODERATE KPANIC flag: NO Patch: crypto: ccp - Do not initialize SNP for ioctl(SNP_VLEK_LOAD) Commit: 61cf5eef20657bff9ca235fe938a99ce5ff65c06 Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=61cf5eef20657bff9ca235fe938a99ce5ff65c06 Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-64308 Analysis date: Sat, 25 Jul 2026 13:29:31 -0400 ActionableScore: 4 ActionableScore lower bound: 2 Actionable bucket: Borderline manual review recommended / possible Actionable Moderate Manual review required: YES Summary: A local SEV/SNP management ioctl could unnecessarily initialize and shut down SNP state when SNP was not already initialized, potentially disrupting global virtualization state and causing a host DoS on AMD SEV/SNP systems running KVM VMs. ====================================================================== ABOUT THIS REPORT ====================================================================== The original Linux kernel CVE announcement for CVE-2026-64308 is available here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-64308 The original announcement does not normally provide a security severity estimate, CVSS assessment, or enough information to determine whether the reported kernel bug represents a practically relevant security issue. This report was generated by AL-KERNEL, an AI-assisted Linux kernel vulnerability analysis system developed by Alexander Larkin. It combines an autonomous classifier with LLM-assisted technical analysis and a separate ActionableScore mechanism. The purpose of this report is to prioritize Linux kernel CVEs before manual review, identify cases that require prompt investigation, and support automatic closure of issues that are unlikely to have meaningful security impact. Published priority for this report: MODERATE REGULAR Manual review required: YES A detailed explanation of the methodology and priority rules is included at the end of this message. ====================================================================== AL-KERNEL CLASSIFICATION RESULT ====================================================================== CVE-2026-64308 MODERATE CHECK WITH IMPACT FROM ORIG NN LOW Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H';CWE-754;CWE-703;CWE-362;Other CVSS 'AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H';BEST CVSS score: '4.7';DESCR 'The SNP_VLEK_LOAD ioctl could implicitly initialize SNP state and then shut it down when SNP was not already initialized. On an AMD SEV/SNP host this can disturb global SEV state while normal KVM VMs are running, and the reported risk is that MSR_VM_HSAVE_PA may be cleared globally so a later VMRUN can fault and crash the host. For the CVSS the PR:L is used for the paranoid score because access to /dev/sev may be delegated to a local management process or reduced capability service account rather than only full host administration. The issue is local and is not directly network reachable. Impact is denial of service against the host. No confidentiality or integrity impact is assigned because the patch indicates global hardware state disruption rather than a memory corruption primitive.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Borderline manual review recommended / possible Actionable Moderate (with actual score 3) YES INIT IMPROVEONLY INCREASED_FROM_LOW_BASED_ON_REQUIREMANUALCHECK DECREASED_TO_MODERATEREG_BASED_ON_ACTIONABLESCORELESSTHAN5 YES NO checked ====================================================================== ACTIONABLESCORE ANALYSIS ====================================================================== ActionableScore=4 ActionableScoreLower=2 ## 1. ActionableScore * Conservative score: 2 * Paranoid score: 4 * Final recommended bucket: **Borderline manual review recommended / possible Actionable Moderate** ## 2. Signal breakdown Conservative signals: * +1 Firmware-mediated device/global state influence: the affected ioctl drives AMD SEV/SNP firmware state transitions. * +1 Reliable kernel crash / strong DoS concern: the commit discussion describes possible host crash when later VMRUN hits bad global SEV state. * +1 Availability impact realistic: if triggered on an affected virtualization host, the impact can be host-level DoS affecting active VMs. * +1 Privileged device-management / virtualization state path: the bug affects SEV/SNP initialization and shutdown state, including security-sensitive VM execution state. * -2 Requires privileged access in typical deployments: writable /dev/sev access is normally restricted to host administration or virtualization management components. * -1 Hardware/configuration dependent: requires AMD SEV/SNP-capable host, relevant firmware state, and active KVM VM context. Paranoid adjustment: * Privilege penalty reduced from -2 to -1 because /dev/sev access may be delegated to a reduced-privilege management daemon, service account, or containerized host-management component rather than full interactive host root. * Rare/configuration penalty not applied in the paranoid score because SEV/SNP hosts are exactly the relevant deployment class, and host crash of active VMs is operationally significant there. No added signals: * No generic memory corruption signal: the patch does not show UAF, OOB write, double free, type confusion, refcount misuse, or arbitrary write. * No confidentiality or integrity signal: the evidence supports global SEV/SNP state disruption and DoS, not data disclosure or privilege escalation. * No remote/network signal: the path is a local ioctl, not packet-triggered. ## 3. Reachability analysis The bug is reachable through the SEV device ioctl path, specifically SNP_VLEK_LOAD, when SNP has not already been initialized. In typical deployments this requires privileged access to /dev/sev, so the conservative interpretation treats it as admin-only. A more paranoid interpretation treats it as PR:L-like in practical triage terms if a reduced-privilege virtualization service or delegated management account can issue SEV ioctls without full host-root authority. The path is not remotely reachable by network traffic. It is deployment-specific to AMD SEV/SNP virtualization hosts and requires relevant firmware and KVM activity. The most concerning condition is an active host running normal VMs while this ioctl path performs an unnecessary SNP init/shutdown sequence and potentially disrupts global SEV state. Call-site confidence: medium. The changed function and immediate behavior are visible, but the exact downstream crash depends on SEV firmware and later KVM VMRUN behavior described in the commit context. ## 4. Severity interpretation This behaves more like a specialized virtualization host DoS than an Important-class memory corruption vulnerability. The realistic impact is availability loss on affected AMD SEV/SNP hosts, potentially crashing the host or disrupting active VMs. The theoretical severity is higher than an ordinary local correctness bug because it touches global virtualization hardware state, but the patch does not support LPE, C/I impact, or a strong memory corruption primitive. Overall, this should not be treated as a generic low-risk cleanup, but it also does not reach Strong Important without additional evidence of privilege escalation, memory corruption, or broader reachability. ## 5. One-sentence report phrase A local SEV/SNP management ioctl could unnecessarily initialize and shut down SNP state when SNP was not already initialized, potentially disrupting global virtualization state and causing a host DoS on AMD SEV/SNP systems running KVM VMs. ## 6. Manual review recommendation MANUAL CHECK REQUIRED Manual review is required because the practical risk depends heavily on /dev/sev permissions, virtualization management delegation, SEV/SNP firmware behavior, and whether active KVM VMs can reliably hit the described VMRUN fault after the ioctl sequence. ====================================================================== UPSTREAM PATCH SUMMARY ====================================================================== Patch: crypto: ccp - Do not initialize SNP for ioctl(SNP_VLEK_LOAD) Commit: 61cf5eef20657bff9ca235fe938a99ce5ff65c06 Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=61cf5eef20657bff9ca235fe938a99ce5ff65c06 Commit description: 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? The SEV firmware docs for SNP_VLEK_LOAD note: > On SNP_SHUTDOWN, the VLEK is deleted. That is, the initialization/shutdown wrapper here is pointless, because the firmware immediately throws away the key anyway. Instead, refuse to do anything if SNP has not been previously initialized. This is an ABI break: before, this was a no-op and almost certainly a mistake by userspace, and now it returns -ENODEV. ABI compatibility could be maintained here by simply returning 0 in the check instead. Fixes: ceac7fb ("crypto: ccp - Ensure implicit SEV/SNP init and shutdown in ioctls") Reported-by: Sashiko Assisted-by: Gemini:gemini-3.1-pro-preview Link: https://sashiko.dev/#/patchset/20260324161301.1353976-1-tycho%40kernel.org CC: Signed-off-by: Tycho Andersen (AMD) Reviewed-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman Changed files: drivers/crypto/ccp/sev-dev.c Diff excerpt: Not included in this email. See the upstream URL for the full patch. Full patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=61cf5eef20657bff9ca235fe938a99ce5ff65c06 ====================================================================== DETAILED REPORT METHODOLOGY ====================================================================== The original Linux kernel CVE announcement for CVE-2026-64308 can be found here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-64308 The original CVE announcement normally does not include a security-level estimate. In particular, it may not contain a CVSS assessment, an impact level, or enough information to determine whether the reported bug is a practically relevant security issue. One purpose of this parallel CVE list is to provide that missing technical and prioritization information. The original goal of the AL-KERNEL project was to prioritize Linux kernel CVE analysis automatically before manual review. The system can also help identify non-security issues that may be suitable for automatic closure. This report was generated by AL-KERNEL, an AI-assisted Linux kernel vulnerability analysis system developed by Alexander Larkin. The first analysis stage combines an autonomous classifier with additional LLM-based analysis. The autonomous classifier runs locally on a CPU and is based on a backpropagation neural network. Together, these mechanisms produce a technical vulnerability description, identify likely weakness types, estimate CVSS severity, and provide input for ActionableScore. Two CVSS estimates are retained because incomplete kernel vulnerability information often permits more than one defensible interpretation: Conservative CVSS vector: AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H The Best / paranoid CVSS vector: AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H The Best / paranoid CVSS score: 4.7 The conservative vector represents a lower-impact interpretation. The Best/paranoid vector intentionally represents a plausible upper-bound interpretation and should not automatically be treated as demonstrated real-world impact. CVSS may also need to be adjusted for a particular Linux deployment, because actual reachability, privileges, enabled kernel configuration, hardware, namespaces, exposed device nodes, and other environmental conditions can differ significantly between systems. A separate ActionableScore mechanism evaluates practical remediation urgency. Its analysis may include reachability, attack prerequisites, subsystem exposure, memory-corruption characteristics, denial-of-service reliability, and possible confidentiality, integrity, or privilege-escalation impact. Conservative ActionableScore: 2 Paranoid ActionableScore: 4 The final base severity is taken directly from the second tab-separated field of the AL-KERNEL classification result. ActionableScore does not replace or independently override that final AL-KERNEL decision, and if ActionableScore adjusted impact level of ALKERNEL, then you would see self-readable flags above like INCREASED_TO_HIGH_BASED_ON_ACTIONABLESCOREHIGHEREQTHAN7. For an AL-KERNEL result of MODERATE, this report uses the following additional presentation split: ActionableScore below 5 -> MODERATE REGULAR ActionableScore 5 or more -> MODERATE 7.0 The distinction between MODERATE REGULAR and MODERATE 7.0 makes it possible to identify Moderate issues that should receive manual analysis and fixes before lower-priority MODERATE REGULAR issues. In many cases, MODERATE REGULAR fixes may wait for a later rebase or routine update. There is one override in which MODERATE REGULAR becomes MODERATE 7.0 even when the ActionableScore is below 5. When the AL-KERNEL result contains the KPANIC flag, a MODERATE result is always presented as MODERATE 7.0. The KPANIC flag selected with few regexps without usage of AI at all, so it helps to detect cases when Kernel Crash happens and similar (to filter False-Negative results from the LLM usage). KPANIC indicates that a reliable kernel crash, kernel panic, or similarly serious kernel availability impact was identified by the classification workflow. AL-KERNEL base severity for this report: MODERATE KPANIC detected for this report: NO Published priority for this report (same as in Subject): MODERATE REGULAR These results are intended to support engineering triage. They are machine-generated estimates, and cases marked for manual review should be validated by a human security engineer before final disposition. For more info read docs linked from here: https://kernelcve.org/ (and you can submit you own patch there to generate such a report for non-existant CVE-id yet). Note that in many cases this AI tool selects higher severity, than real is (means you can expect Importants instead of Moderate 7.0 or Moderates 7.0 instead of regular Moderates). If you see such cases, please use reply email interface to add additional manual analyses info to this particular CVE. And please, please, let me know when you see Lows instead of Importants or Important instead of Low (because particular for such cases I need to tune this AI tool to make it better for this one and next similar). My contact email for such notifications is alexanjelausa@gmail.com (and both send reply to CVE record itself too and see "reply" button below for howto reply).