CVE-2026-63794: Patch and Reboot Linux KVM AMD SEV Hosts

CVE-2026-63794 is a Linux KVM host-kernel issue in AMD SVM/SEV code. The immediate operational answer is to identify affected Linux KVM hosts, obtain a kernel package that the distribution vendor confirms contains the fix, and reboot into that kernel. Windows guest inventories are not the starting point: a Windows VM does not contain the affected Linux KVM code. The relevant system is the Linux hypervisor host.

What changed​

The defect is a bounds error in the AMD SEV-related KVM path in arch/x86/kvm/svm/sev.c. A destination buffer is 4,096 bytes long, but under the problematic offset combination—s_off=0 and d_off=1—the Platform Security Processor can round a requested 4,097-byte transfer up to 4,112 bytes. That can overflow the 4,096-byte destination buffer by up to 15 bytes.
The correction constrains the transfer length using the remaining destination-page space: len is bounded by PAGE_SIZE - d_off. In practical terms, the fix prevents the transfer request from extending beyond the destination buffer after the destination offset is taken into account.
The supplied record identifies AMD SVM/SEV code and an encryption-related path, but it does not provide a complete runtime reachability or exploitability model. Administrators should not assume that exposure is limited only to hosts with a particular SEV setting enabled, nor should they infer that every host with AMD hardware is exploitable. The remediation decision should be based on vendor confirmation that the running Linux kernel includes the correction.

Linux stable line	NVD unaffected designation	Practical reading
5.10	5.10.260	The NVD record designates 5.10.260 as unaffected within the 5.10 line.
5.15	5.15.211	The NVD record designates 5.15.211 as unaffected within the 5.15 line.
6.1	6.1.177	The NVD record designates 6.1.177 as unaffected within the 6.1 line.
6.6	6.6.144	The NVD record designates 6.6.144 as unaffected within the 6.6 line.

Because the supplied version ranges use a lessThanOrEqual relationship, the natural reading is that these designated versions and subsequent releases in the same upstream stable lines include the corrected state. That does not mean those are the only fixed kernel lines, and it does not replace a distribution vendor’s advisory or package changelog for backported enterprise kernels.

What the available record establishes​

The supplied NVD material identifies CVE-2026-63794 as a Linux kernel issue associated with KVM’s AMD SVM/SEV implementation. It identifies the relevant source area as arch/x86/kvm/svm/sev.c and describes affected versions beginning with Linux kernel 4.16, with versions before 4.16 designated as unaffected.
The record provides unaffected designations for upstream 5.10, 5.15, 6.1, and 6.6 stable lines. Those versions are useful reference points for administrators running upstream-oriented kernels and for maintainers who need to establish where the stable fix landed. They are not a substitute for vendor package analysis on systems that use distribution-maintained kernels.
The record does not supply a complete exploitability analysis, access model, or universal runtime exposure test. That limitation matters. The presence of AMD virtualization hardware, an AMD KVM module, SEV-related CPU capability indicators, or a particular module parameter is local configuration evidence—not a definitive determination that a host is exploitable or unaffected.
The decisive remediation check is simpler: verify that the vendor-confirmed fixed kernel package is installed, then verify that the host has rebooted into that fixed kernel.

Host versus guest: where to investigate​

CVE-2026-63794 concerns Linux KVM host code. A Windows Server or Windows 11 guest may be running on an affected host, but the guest operating system is not the component that needs the kernel fix. The first inventory target is therefore the Linux virtualization host that provides KVM, not the operating systems inside its virtual machines.
This distinction is especially important where separate teams own guest systems and host infrastructure. A guest-management team can correctly report that Windows updates are current while the Linux KVM host underneath those guests still requires a kernel update. Conversely, the existence of Windows guests does not establish that the host uses AMD SVM/SEV functionality or that it runs an affected kernel.
The operational workflow is:

1. Identify Linux KVM hosts.
2. Record the kernel currently booted on each host.
3. Determine whether the host’s kernel package is vendor-confirmed to contain the CVE-2026-63794 fix.
4. Install the fixed package where required.
5. Reboot into the fixed kernel.
6. Record post-reboot evidence.

Evidence workflow for administrators​

The following commands are optional local evidence-gathering tools. They are not a substitute for a vendor advisory, a package changelog entry, or other vendor confirmation that the installed kernel contains the CVE-2026-63794 correction.

1. Record the running kernel​

Start on the Linux KVM host:

uname -r
uname -a
cat /proc/version

The key result is:
uname -r
That output identifies the kernel currently running. Installing an updated kernel package is not enough by itself; the host must boot the updated kernel before the correction is active.
Save the result in the maintenance record before and after remediation.

2. Identify the package associated with the booted kernel​

Package names and boot-image locations vary among distributions and local build processes, so use the following only as examples of how to collect package evidence.
On systems using RPM package management, this can identify the package associated with the running kernel image when the image is present at the expected location:
rpm -qf "/boot/vmlinuz-$(uname -r)" 2>/dev/null
On systems using Debian package management, this can query a kernel image package matching the running release:
dpkg-query -W -f='${Package}\t${Version}\n' "linux-image-$(uname -r)" 2>/dev/null
If either command does not return useful information, document the result and use the organization’s normal package inventory method. The important evidence is the running kernel release, the installed kernel package version, and vendor confirmation that this package includes the fix.

3. Gather local AMD KVM and SEV configuration evidence​

Where relevant to the host’s role, administrators may record whether the AMD KVM module is loaded:
lsmod | grep -E '^kvm_amd|^kvm '
They may also inspect information exposed by the currently loaded module:
modinfo kvm_amd 2>/dev/null
If the module is not loaded, that does not prove that the host is unaffected. It can simply mean that KVM workloads are not active at that moment, that the module has not been loaded, or that the host uses another virtualization arrangement.
Where the system exposes SEV-related module parameters, this optional command records those current values:

for p in /sys/module/kvm_amd/parameters/sev*; do
    [ -e "$p" ] && printf '%s = %s\n' "$p" "$(cat "$p")"
done

A host can also expose SEV-related processor capability indicators through /proc/cpuinfo:
grep -m1 '^flags' /proc/cpuinfo | tr ' ' '\n' | grep '^sev'
These observations answer narrow local questions only:

• CPU flags can indicate processor-advertised capabilities.
• Module status can show whether AMD KVM is currently loaded.
• Module parameter files can show values exposed by the loaded kernel module.

They do not provide a definitive CVE-2026-63794 exposure test. The supplied record does not establish that a particular combination of flags, loaded modules, parameters, or log messages fully determines reachability. Use the information as inventory context, then rely on vendor confirmation of the fixed kernel for remediation.

4. Confirm the fixed package with the kernel vendor​

For a vendor-maintained kernel, seek evidence that specifically identifies CVE-2026-63794 or clearly maps the package to the correction. Suitable evidence may include:

• A distribution security advisory.
• A vendor security tracker entry.
• A package changelog.
• Vendor support confirmation.
• Internal platform engineering confirmation tied to the vendor’s package metadata.

A local changelog search can be useful, but absence of the CVE string is not proof that the package lacks the fix. Vendors may use different identifiers, summarize security backports, or document a correction through an advisory rather than an installed package changelog.
Optional local searches include:
rpm -q --changelog "$(rpm -qf "/boot/vmlinuz-$(uname -r)" 2>/dev/null)" 2>/dev/null | grep -i -C 3 'CVE-2026-63794'
and:
zgrep -i 'CVE-2026-63794' /usr/share/doc/linux-image-*/changelog*.gz 2>/dev/null
Treat these as supporting evidence. The central decision remains whether the kernel vendor confirms that the package installed on the host contains the correction.

5. Reboot and verify the running kernel​

After installing the vendor-confirmed fixed kernel, reboot through the organization’s established maintenance and change-control process.
After the reboot, verify the active release:
uname -r
Then repeat the package identification method used before maintenance. The post-reboot evidence should demonstrate both of the following:

1. A fixed kernel package is installed.
2. The host is running that fixed kernel rather than an older kernel still resident from before the maintenance window.

If local configuration evidence was collected before the update, it can be collected again afterward for operational documentation. It should not be confused with the actual patch-verification step.

Custom-kernel and upstream-maintainer notes​

Organizations building their own kernels should review the stable-tree state associated with the NVD designations and ensure that the source branch includes the correction that bounds len by PAGE_SIZE - d_off.
The supplied stable-line references can be reviewed through the corresponding kernel.org stable tags:

• Linux 5.10.260: <Making sure you're not a bot!>
• Linux 5.15.211: <Making sure you're not a bot!>
• Linux 6.1.177: <Making sure you're not a bot!>
• Linux 6.6.144: <Making sure you're not a bot!>

For a custom kernel, a version-string comparison alone is not sufficient evidence if the tree has been rebased, partially backported, or assembled from selected patches. Maintainers should inspect the applicable stable history and confirm that the source contains the destination-length bound that prevents a transfer from extending past the destination page.
A practical custom-kernel verification question is: does the relevant SEV transfer path cap the length using the remaining destination space, PAGE_SIZE - d_off, before the Platform Security Processor transfer can be rounded? If not, the tree needs the relevant correction or an equivalent verified fix.

Timeline​

The supplied material should be used for technical remediation and source-history review, but unsupported publication or modification dates should not be treated as established facts here. The relevant operational timeline is the organization’s own: identify affected Linux KVM hosts, obtain a vendor-confirmed fixed kernel, schedule the reboot, and retain post-reboot verification evidence.

Action checklist for admins​

• Identify Linux KVM hypervisor hosts; do not begin with Windows guest inventories.
• Record the running kernel with uname -r.
• Record the installed kernel package using the host’s normal package inventory process.
• Treat AMD KVM module status, SEV-related parameters, and CPU capability indicators as local configuration evidence only.
• Do not use SEV triage commands as a definitive exposure or exploitability test.
• For upstream-oriented kernels, compare against the NVD unaffected designations for the applicable stable line.
• For custom kernels, verify that the source includes the PAGE_SIZE - d_off destination-length bound or an equivalent correction.
• For vendor-maintained kernels, obtain vendor confirmation that the package contains the CVE-2026-63794 fix.
• Install the fixed kernel package and reboot through normal maintenance controls.
• Verify after reboot that the fixed kernel is actually running.
• Preserve the running-kernel release, package information, and vendor confirmation in the maintenance record.

What CVE-2026-63794 changes for KVM SEV operators​

CVE-2026-63794 is a focused Linux host-kernel maintenance issue involving a concrete buffer-length defect in KVM’s AMD SEV-related code. The corrected code limits the transfer length to the destination page space remaining after d_off, preventing a PSP-rounded transfer from exceeding the 4,096-byte destination buffer.
The response should remain equally focused. Administrators do not need to turn this into a broad Windows guest alert, and they should not claim a universal exposure model that the supplied record does not provide. The useful work is to patch Linux KVM hosts to vendor-confirmed fixed kernels and verify that those kernels are booted.
Looking ahead, this is also a reminder that virtualization security inventories should separate host kernel state, guest operating-system state, hardware capability, loaded modules, and package provenance. Keeping those fields distinct makes future responses faster: it directs patch teams to the Linux hypervisor code that actually needs remediation while preserving the evidence needed to prove that the corrected kernel is in service.

---

References​

1. Primary source: NVD / Linux Kernel
   Published: 2026-07-20T01:05:46-07:00
   
   

   NVD - CVE-2026-63794

   nvd.nist.gov
2. Security advisory: MSRC
   Published: 2026-07-20T01:05:46-07:00
   Original feed URL
   
   

   Security Update Guide - Microsoft Security Response Center

   msrc.microsoft.com