KVM: s390: Fix potential races in dat skey functions
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 7.2.9
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
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.
Timeline
- CVE published
- Record last updated
Affected versions
- Linux Linux
From 8e03e8316eb242af307d1c789d09f1a1457cf9a3 · fixed in c958f0498891203fddf2764b28f8b102c6bfd719; From 8e03e8316eb242af307d1c789d09f1a1457cf9a3 · fixed in 27554b9505ddfc0aeab466aeb60929dfa17284c7
- Linux Linux
7.0
- KernelLinux
From 7.0.0 · fixed in 7.2.9