CVE-2023-52639

What it actually does

Race condition in KVM s390 vsie shadow gmap creation allows gmap->private to be observed as NULL in kvm_s390_vsie_gmap_notifier, resulting in a kernel crash.

Why it matters to the business

Virtual machine hosts on IBM Z systems may experience sudden kernel panics during guest shadow page table operations, leading to unplanned downtime and loss of running workloads.

How an attack unfolds

An attacker with the ability to trigger concurrent shadow gmap creation and notifier callbacks on an s390 KVM host can win the race window before gmap->private is set, forcing a NULL dereference and crash.

How to fix it

Update the Linux kernel to a version containing commit 5df3b81a567eb565029563f26f374ae3803a1dfc or later; rebuild and reboot affected hosts.

How to confirm the fix worked

Confirm the running kernel contains commit 5df3b81a567eb565029563f26f374ae3803a1dfc; exercise vsie shadow paths under load and verify absence of NULL dereference crashes in the gmap notifier.

Typical attack path

1. Obtain local access or control a guest that can exercise KVM s390 vsie paths
2. Trigger concurrent gmap_shadow allocation and gmap notifier execution
3. Cause the notifier to read gmap->private before the assignment completes
4. Trigger NULL pointer dereference and host kernel panic

How to detect it

Review kernel logs for oops or panic entries mentioning kvm_s390_vsie_gmap_notifier or gmap private field access; correlate with periods of high vsie shadow activity.

What your security team should do

• Prioritize patching s390 KVM hosts within the next maintenance window
• Monitor for host kernel crashes referencing kvm_s390_vsie_gmap_notifier
• Test the fixed kernel in a staging environment before broad rollout