CVE-2026-98650: KVM: s390: Fix potential races in dat skey functions
In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: Fix potential races in dat skey functions
When datcondsetstoragekey() finds a large page, it will conditionally set the storage key in absolute memory using largecrstetophys() to get the absolute address.
There is a race window between datentrywalk() and largecrstetophys(): the large page could have been split concurrently, and largecrstetophys() might be called with a crste that does not designate a large page, leading to crashes.
Similar issues were also present in datsetstoragekey().
datgetstoragekey() and datresetreferencebit() did instead check for a potential concurrent splitting of the large page, but then handled it incorrectly.
Fix by performing a READONCE on the crste pointer, checking and using the result, instead of dereferencing the pointer again. In case a race is detacted, try datentrywalk() again.
Affected Software
Event History
Frequently Asked Questions
What conditions are required for this issue to occur?
The affected code path must encounter a large page while another execution context concurrently splits that large page. The race occurs between walking the DAT entry and converting a large-page CRSTE to an absolute address.
What is the likely impact if the race is triggered?
A stale CRSTE may be treated as designating a large page after that page has been split. This can cause the KVM s390 DAT storage-key functions to crash.
Which functions were affected by the race handling?
The issue affected dat_cond_set_storage_key() and dat_set_storage_key(). dat_get_storage_key() and dat_reset_reference_bit() attempted to detect concurrent large-page splitting but handled the detected race incorrectly.
How is the issue fixed?
The fix reads the CRSTE pointer with READ_ONCE, checks and uses that same result rather than dereferencing the pointer again. If a concurrent split is detected, it retries dat_entry_walk().