---
id: "CVE-2026-98650"
kind: "vulnerability"
aliases: ["CVE-2026-98650"]
title: "Linux kernel s390 KVM: race while handling storage keys can crash host"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "other"
products: []
ecosystems: []
tags: ["kvm", "linux-kernel", "other", "s390"]
not_affected_if: ["kvm-not-in-use", "non-s390-architecture"]
published_at: "2026-10-18T16:17:18+00:00"
first_seen_at: "2026-10-23T21:57:16+00:00"
updated_at: "2026-10-25T05:19:40+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98650", "first_seen_at": "2026-10-23T21:57:16+00:00"}]
---

# Linux kernel s390 KVM: race while handling storage keys can crash host

A race in the Linux kernel's s390 KVM storage-key code lets a large page be split concurrently, so a function may be called with a page-table entry that is not a large page, causing a crash. The sources describe the crash but do not state a confidentiality or code-execution impact.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check whether the host runs Linux on IBM s390 hardware with KVM enabled (`uname -m` reports `s390x`, and `/dev/kvm` exists).
- Compare the running kernel with the fixed release listed in the NVD entry (https://nvd.nist.gov/vuln/detail/CVE-2026-98650); the fixed version is unknown from the sources.

## Fix

- Update the Linux kernel to a release that includes the upstream fix for the s390 KVM dat storage-key races; the exact fixed version is unknown from the sources.
- Reboot into the patched kernel after updating.

## Timeline

- 2026-10-23T21:57:16+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98650

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_