CVE-2026-80853 in Linux
Summary
by MITRE • 09/04/2026
In the Linux kernel, the following vulnerability has been resolved:
KVM: SEV: Allocate full pages for {DE,EN}CRYPT ops on SNP-enabled hosts
When {de,en}crypting memory of an SEV or SEV-ES guest on an SNP-enabled
host via a temporary buffer, allocate a full 4KiB page for the buffer to ensure the page containing the buffer is wholly owned by KVM, i.e. won't be concurrently allocated and accessed by other kernel code while KVM is using the buffer to {de,en}crypt memory. On SNP-enabled platforms, when
sending SEV/SEV-ES commands that trigger firmware writes to memory, the to-be-written page(s) must be (temporarily) assigned to Firmware (as required by the SNP architecture, to guard against using such commands as gadgets to attack SNP guests). See snp_map_cmd_buf_desc() and friends.
Unfortunately, transferring ownership of a page to Firmware makes the page inaccessible to software, and thus writes generate RMP #PF violations. If KVM uses a sub-page allocation for its temporary buffer, some other actor in the kernel can allocate and use the other portions of the page, and thus trigger unexpected (and seemingly spurious) RMP #PF violations due to software attempting to access a Firmware-owned page.
BUG: unable to handle page fault for address: ffff906ae30f0300 #PF: supervisor write access in kernel mode #PF: error_code(0x80000003) - RMP violation PGD 6b1b80d067 P4D 6b1b80d067 PUD 100231e2063 PMD 10055a88063 PTE 80000100630f0163 SEV-SNP: PFN 0x100630f0 unassigned, dumping non-zero entries in 2M PFN region: [0x10063000 - 0x10063200]
Oops: Oops: 0003 [#1] SMP
CPU: 70 UID: 0 PID: 10658 Comm: svw_WaiterThrea Tainted: G U W O 7.1.0-smp--c22293789940-seanjc-next #1 PREEMPTLAZY Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE
Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026 RIP: 0010:memset+0xf/0x20 Call Trace: <TASK> __kvmalloc_node_noprof+0x2a4/0x710 do_getxattr+0x4e/0x130 path_getxattrat+0x125/0x1b0 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f3a22cb6daa </TASK> Modules linked in: kvm_amd kvm irqbypass vfat fat ccp k10temp sha3 libsha3 i2c_piix4 gq(O) cdc_acm xhci_pci xhci_hcd gsmi: Log Shutdown Reason 0x03 CR2: ffff906ae30f0300 ---[ end trace 0000000000000000 ]---
RIP: 0010:memset+0xf/0x20 Kernel panic - not syncing: Fatal exception Kernel Offset: 0x39e00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) gsmi: Log Shutdown Reason 0x02
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/07/2026
The Linux kernel vulnerability identified in the KVM subsystem for AMD Secure Encrypted Virtualization with Secure Nested Paging involves a critical memory management flaw related to temporary buffer allocation during cryptographic operations. When handling SEV or SEV-ES guest memory encryption and decryption on SNP-enabled hosts, the hypervisor utilizes temporary buffers to prepare data before sending commands to the AMD Platform Security Processor firmware. The core technical flaw lies in the fact that these temporary buffers were previously allocated using sub-page allocations rather than full 4KiB pages. This allocation strategy creates a race condition where multiple kernel components can access different parts of the same physical page simultaneously, leading to severe integrity and availability issues within the virtualization layer.
The operational impact stems from the specific requirements of the SNP architecture regarding memory ownership transitions. When KVM sends SEV or SEV-ES commands that trigger firmware writes, it must temporarily transfer ownership of the affected pages to the AMD Firmware. This transition is a security measure designed to prevent attackers from using these command mechanisms as gadgets to compromise SNP guests by manipulating shared state. However, once a page is assigned to Firmware for this purpose, it becomes inaccessible to standard software execution contexts. If KVM uses only a portion of a larger allocated page for its cryptographic buffer while the rest remains unassigned or accessible to other kernel subsystems, those other actors may attempt to access their respective portions of that same physical page. Because the entire page is logically owned by Firmware during this window, any such access results in an RMP (RMAP) #PF violation, which manifests as a supervisor write access fault in kernel mode.
This race condition leads directly to system instability and potential denial of service conditions for both the host operating system and potentially the guest virtual machines if not handled gracefully by error recovery mechanisms. The provided crash trace illustrates this clearly, showing an RMP violation occurring during a memset operation within the KVM memory allocation path. The kernel panic indicates that the fault was fatal because it occurred in critical kernel code paths such as attribute retrieval or syscall handling, which rely on stable memory access patterns. The presence of tainted modules and specific CPU registers highlights how this low-level hardware-software interface mismatch can propagate up to cause complete system crashes, disrupting services running on both bare-metal hosts and their associated virtualized workloads.
From a vulnerability classification perspective, this issue aligns with CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization, as the root cause is the lack of exclusive ownership over the memory page during critical firmware interaction windows. It also relates to CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer, since the sub-page allocation allows other kernel code to operate on parts of the buffer that are not intended for their use while the hardware enforces strict access controls based on full-page ownership semantics. In terms of MITRE ATT&CK mapping, this vulnerability could be leveraged in an Availability impact scenario under T1499: Endpoint Denial of Service, where an attacker might trigger repeated RMP violations to crash the host system, or potentially as a primitive for more sophisticated attacks if they can control which kernel subsystems are active during these windows.
Mitigation strategies primarily involve applying the upstream Linux kernel patch that enforces full page allocation for SEV/SEV-ES cryptographic buffers on SNP-enabled platforms. Administrators should ensure their systems are updated to versions of the kernel where this fix is integrated, typically found in stable releases following the commit date associated with the KVM AMD driver updates. Additionally, organizations running workloads on AMD EPYC processors with SNB support enabled should verify that virtualization extensions are correctly configured and monitored for any signs of unexpected RMP violations or kernel panics related to memory management subsystems. Regular auditing of system logs for these specific error codes can help detect attempts to exploit this race condition before it leads to catastrophic failure, although the primary defense remains timely patching of the hypervisor software stack.