CVE-2026-98653 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: Fix _gaccess_shadow_fault()
In some circumstances, it is possible that the page of nested guest memory that is being shadowed is not present at all in the parent guest gmap. dat_entry_walk() will not find any leaf entry and return with -ENOENT, which will erroneously be propagated all the way to userspace.
Fix by manually calling gmap_link() on the memory of the nested guest that is being shadowed if the mapping was not already present.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/19/2026
The Linux kernel's KVM implementation for IBM Z architecture contains a specific flaw within the _gaccess_shadow_fault function, which is critical for managing memory access in nested virtualization scenarios. This vulnerability arises during the process of shadowing guest physical addresses to host virtual addresses when dealing with nested guests. In this context, the parent guest acts as an intermediary layer between the hypervisor and the actual hardware resources, while the nested guest operates within that parent environment. The core issue occurs when the page table entries corresponding to the memory region being accessed by the nested guest are not present in the global map of the parent guest. This absence can happen due to various reasons such as lazy allocation or specific memory management policies where pages are only mapped upon actual access rather than pre-allocation.
When a nested guest attempts to access its virtualized memory, the KVM subsystem invokes dat_entry_walk to locate the corresponding leaf entry in the page tables of the parent guest's global map. Under normal circumstances, this function traverses the hierarchical page table structure to find valid mappings that translate the guest physical address into host virtual addresses. However, if the specific page is not yet mapped or present in the parent guest's gmap, dat_entry_walk fails to locate a leaf entry and returns an error code indicating no such entity exists, specifically -ENOENT. This return value signifies that the required mapping was not found during the traversal process.
The critical flaw lies in how this error condition is handled upstream. Instead of treating the absence of a page table entry as a signal requiring dynamic allocation or fallback handling, the current implementation erroneously propagates the -ENOENT error code directly up through the call stack and eventually exposes it to userspace applications interacting with the KVM interface. This behavior violates expected operational semantics because memory access faults should typically result in page fault exceptions that trigger appropriate kernel-side resolution mechanisms rather than immediate failure reports sent back to user-level processes. Such incorrect propagation can lead to unexpected application crashes, denial of service conditions for virtualized workloads, or potential information leakage if error codes expose internal kernel states improperly.
From a technical perspective, this issue represents an improper handling of exceptional conditions within memory management subsystems, aligning with CWE-754: Improper Check for Unusual or Exceptional Conditions and potentially CWE-20: Improper Input Validation depending on how the userspace interprets these errors. In terms of attack vectors, while primarily a stability issue rather than a direct exploitation vector, it could contribute to availability impacts classified under MITRE ATT&CK T1499: Endpoint Denial of Service if an attacker can trigger repeated memory accesses that consistently hit unmapped pages in nested guest scenarios. The lack of proper fallback logic means the system fails gracefully and instead presents hard errors that disrupt normal operation.
The resolution involves modifying _gaccess_shadow_fault to detect when dat_entry_walk returns -ENOENT due to missing mappings rather than other fatal errors. Upon detecting this specific condition, the function now manually invokes gmap_link() on behalf of the nested guest's memory region being shadowed. This action effectively creates the necessary mapping in the parent guest's global map if it does not already exist, allowing subsequent access attempts to succeed without triggering erroneous error propagation. By ensuring that missing mappings are dynamically resolved rather than reported as fatal errors, the fix restores correct operational behavior for nested virtualization workloads and prevents spurious failures from reaching userspace applications.
Mitigation strategies involve applying this kernel patch or updating to a version of Linux where this correction is included. Administrators running KVM with s390 architecture should verify their kernel versions against vendor advisories to ensure they have received the fix for _gaccess_shadow_fault(). For environments utilizing nested virtualization extensively, monitoring logs for unexpected guest failures related to memory access faults can help identify systems still vulnerable before patching is applied. Regular updates and adherence to recommended security practices regarding hypervisor configuration remain essential to maintaining system integrity in complex multi-layered virtualized deployments.