CVE-2026-98650 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: Fix potential races in dat skey functions
When dat_cond_set_storage_key() finds a large page, it will conditionally set the storage key in absolute memory using large_crste_to_phys() to get the absolute address.
There is a race window between dat_entry_walk() and large_crste_to_phys(): the large page could have been split concurrently, and large_crste_to_phys() might be called with a crste that does not designate a large page, leading to crashes.
Similar issues were also present in dat_set_storage_key().
dat_get_storage_key() and dat_reset_reference_bit() did instead check for a potential concurrent splitting of the large page, but then handled it incorrectly.
Fix by performing a READ_ONCE on the crste pointer, checking and using the result, instead of dereferencing the pointer again. In case a race is detacted, try dat_entry_walk() again.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel's KVM implementation for the s390 architecture contains critical concurrency flaws within its dynamic address translation storage key management functions. These vulnerabilities arise from improper handling of large page structures during concurrent memory operations, specifically affecting the functions responsible for setting and retrieving storage keys as well as resetting reference bits. The core issue stems from a race condition where the state of a large page can change between the time it is identified and the time its physical address is calculated or manipulated. This lack of atomicity in checking and acting upon memory management structures creates opportunities for kernel instability, potentially leading to system crashes or unauthorized access if exploited by malicious virtual machines attempting to destabilize the host environment.
The primary technical flaw exists within the dat_cond_set_storage_key() function when it encounters a large page descriptor. The code attempts to convert the control register storage entry into a physical address using large_crste_to_phys(). However, there is an unsafe window between the initial walk of the data translation entries via dat_entry_walk() and this conversion step. During this interval, another thread or interrupt handler may split the large page into smaller pages. If this occurs, the crste pointer used in the subsequent call to large_crste_to_phys() no longer points to a valid large page structure. Consequently, the function proceeds with stale data that does not designate a large page, leading to incorrect memory address calculations and eventual kernel panics due to invalid memory access or corruption of critical system structures.
Similar race conditions were identified in dat_set_storage_key(), which suffers from the same lack of atomicity when managing storage keys for large pages. While other functions such as dat_get_storage_key() and dat_reset_reference_bit() attempted to mitigate this issue by checking for concurrent page splitting, their implementation was flawed. These functions detected that a race condition had occurred but failed to handle it correctly, likely proceeding with invalid assumptions about the memory state or failing to retry the operation safely. This incomplete error handling meant that even when potential corruption was anticipated, the system remained vulnerable to instability because the recovery logic did not adequately restore consistency before continuing execution.
The resolution involves enforcing strict atomicity in accessing control register storage entries by utilizing READ_ONCE on the crste pointer. This ensures that the value read is consistent and prevents partial reads or torn values from being processed. The updated logic checks the result of this single, atomic read operation to determine if the page structure remains valid as a large page. If a race condition is detected during this check, indicating that the page may have been split concurrently, the function does not proceed with invalid assumptions but instead retries the entire dat_entry_walk() process. This retry mechanism ensures that the system operates on current and accurate memory management data, thereby eliminating the window of vulnerability where stale pointers could lead to crashes or security breaches.
From a classification perspective, this vulnerability aligns with CWE-362, which describes concurrent execution using shared resources with improper synchronization. The failure to properly synchronize access to the crste pointer allows for race conditions that compromise system integrity. In terms of attack vectors and defensive mapping, this issue relates to ATT&CK technique T1499, Endpoint Denial of Service, as successful exploitation could lead to kernel panics or system unavailability. Furthermore, it touches upon aspects of memory management security found in CWE-367, Time-of-check Time-of-use (TOCTOU) race conditions, where the state of an object changes between its verification and its use.
Mitigation strategies for this vulnerability primarily involve applying the latest kernel patches that include these synchronization fixes. System administrators should ensure their s390-based virtualization hosts are updated to versions containing the corrected KVM code. For environments running older kernels without immediate patch availability, restricting access to KVM management interfaces and monitoring system logs for signs of instability or unexpected reboots can help mitigate potential exploitation attempts. Additionally, enforcing strict isolation policies between virtual machines reduces the attack surface by limiting the ability of a guest OS to trigger high-frequency memory operations that might exacerbate these race conditions.