diff options
| author | Claudio Imbrenda <imbrenda@linux.ibm.com> | 2026-08-28 13:54:38 +0200 |
|---|---|---|
| committer | Claudio Imbrenda <imbrenda@linux.ibm.com> | 2026-09-01 15:42:28 +0200 |
| commit | 27554b9505ddfc0aeab466aeb60929dfa17284c7 (patch) | |
| tree | dcc0d3ed1b6a5523c1ac6e9a9e4c77d056d6ebbe /scripts/Makefile.thinlto | |
| parent | f3a557067d57ce6ae98d485c8009b223e16f5f36 (diff) | |
| download | linux-next-27554b9505ddfc0aeab466aeb60929dfa17284c7.tar.gz linux-next-27554b9505ddfc0aeab466aeb60929dfa17284c7.zip | |
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.
Fixes: 8e03e8316eb2 ("KVM: s390: KVM page table management functions: storage keys")
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-ID: <20260828115439.145885-8-imbrenda@linux.ibm.com>
Diffstat (limited to 'scripts/Makefile.thinlto')
0 files changed, 0 insertions, 0 deletions
