[CVE-2026-64308][MODERATE REGULAR] crypto: ccp - Do not initialize SNP for ioctl(SNP_VLEK_LOAD)

[CVE-2026-64308][MODERATE REGULAR] crypto: ccp - Do not initialize SNP for ioctl(SNP_VLEK_LOAD)

[AL-KERNEL]

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: <stable@vger.kernel.org>
Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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).