CVE-2026-98928 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Derive GUEST_HAS_SVE from the SVE feature bit at EL2
pkvm_init_features_from_host() takes KVM_ARCH_FLAG_GUEST_HAS_SVE and KVM_ARM_VCPU_SVE from the host separately, but pkvm_vcpu_init_sve() tests the bit while vcpu_has_sve() reads the flag. A host that sets the flag without the bit gets a vCPU with a NULL sve_state that the world switch loads the guest's SVE state from.
Derive the flag from the bit, and drop the protected path's copy of the host's flag, which is dead code since protected VMs are not allowed SVE.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/24/2026
The vulnerability in question resides within the Linux kernel’s KVM implementation for ARM64 architectures, specifically affecting the initialization logic for Secure Virtual Machine (SVM) or Protected KVM environments. The core issue stems from an inconsistency between how the guest's Support for Scalable Vector Extension state is detected and how it is subsequently utilized during virtual CPU context switching. In normal operation, the host kernel determines whether a physical CPU supports SVE by checking specific feature bits exposed through system registers. However, when initializing features for protected VMs via pkvm_init_features_from_host, the code incorrectly treats KVM_ARCH_FLAG_GUEST_HAS_SVE and KVM_ARM_VCPU_SVE as independent inputs derived from the host environment rather than deriving one logically from the other. This architectural flaw creates a scenario where the flag indicating guest SVE capability can be set without the corresponding hardware feature bit being present or correctly aligned, leading to divergent behavior between different initialization paths.
The operational impact of this misalignment is severe and directly compromises system stability and security during virtualization context switches. When pkvm_vcpu_init_sve executes, it relies on testing a specific bit to determine SVE availability. Conversely, the vCPU world switch mechanism, which handles the transition between host and guest execution states, reads the KVM_ARCH_FLAG_GUEST_HAS_SVE flag to decide whether to load or save SVE registers. If the flag is set while the underlying hardware feature check fails or returns null due to the missing bit validation, the system attempts to access a NULL sve_state pointer. This results in a kernel panic or undefined behavior during context switching, effectively causing a denial of service for the affected virtual machine and potentially destabilizing the entire host system if not properly contained within the VM boundaries.
From a technical classification perspective, this flaw aligns with CWE-20: Improper Input Validation, as the code fails to adequately validate that the input flags accurately reflect the actual hardware capabilities before proceeding with state initialization. Furthermore, it relates to CWE-476: NULL Pointer Dereference, since the mismatch leads directly to a null pointer access during the critical world switch operation. In terms of adversary behavior and detection, this vulnerability could be leveraged in an attack scenario categorized under ATT&CK T1059: Command and Scripting Interpreter or more specifically within the context of virtualization escape attempts if an attacker can manipulate VM configuration parameters to trigger the null dereference condition. While primarily a stability issue, such memory corruption bugs often serve as precursors to privilege escalation vectors in complex hypervisor environments where state management is intricate.
The resolution involves refactoring the initialization logic to ensure that KVM_ARCH_FLAG_GUEST_HAS_SVE is strictly derived from the actual SVE feature bit reported by the hardware at EL2 level. This eliminates the possibility of flag-bit mismatch and ensures consistency across all code paths. Additionally, the fix removes a redundant copy of the host's flag within the protected VM initialization path. Since protected VMs are explicitly prohibited from using SVE features for security isolation reasons, this copied flag was dead code that contributed to confusion in the logic flow. By aligning the software state with hardware reality and removing obsolete configuration handling, the vulnerability is mitigated. System administrators should ensure their kernels are updated to include these patches, particularly if they utilize ARM64-based virtualization hosts running protected VMs or sensitive workloads requiring strict isolation guarantees. Regular patch management remains critical as hypervisor vulnerabilities can have cascading effects on all guest instances hosted on compromised infrastructure.