Cloudanix VulnDB

CVE-2026-98930

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A locking mistake in the virtualization layer on certain IBM mainframe systems could let a virtual machine crash the entire host computer.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

A fault during userspace write in __inject_sigp_stop() while a spinlock is held in do_inject_vcpu() can trigger sleeping or deadlock in the s390 KVM IRQ injection path for Stop-and-Store-Status operations.

Why it matters to the business

Virtual machines on s390 hosts may experience sudden crashes or hangs, disrupting workloads that rely on KVM virtualization and forcing unplanned restarts or failovers.

How an attack unfolds

An attacker with access to a guest or host triggers repeated SIGP Stop-and-Store-Status operations on a running vCPU; the pending interrupt handling path attempts a userspace store while the spinlock is held, causing a fault or deadlock that crashes the host kernel.

How to fix it

Update to a Linux kernel containing the referenced fix that returns -EWOULDBLOCK from __inject_sigp_stop() and performs the store-status operation outside the spinlock; apply the patch or newer stable release that includes the scoped_guard and __free() refactor.

How to confirm the fix worked

Confirm the kernel source contains the updated __inject_sigp_stop() logic that sets a status-store flag and performs the store after releasing the lock; verify no spinlock-protected path performs userspace writes for SIGP Stop-and-Store-Status.

Typical attack path

  1. Obtain ability to issue SIGP instructions to a target vCPU
  2. Force the vCPU into the running state
  3. Issue Stop-and-Store-Status operation while vCPU is running
  4. Trigger the faulting userspace write inside the spinlock-held context
  5. Cause kernel panic or deadlock on the host

How to detect it

Inspect kernel logs for spinlock-related warnings or BUG messages originating from do_inject_vcpu or kvm_s390_set_irq_state; review audit logs for unusual SIGP Stop-and-Store-Status sequences preceding a host crash.

What your security team should do

  • Prioritize kernel upgrades on all s390 KVM hosts within the next maintenance window
  • Monitor upstream stable branches for the official backport commit
  • Temporarily restrict untrusted guest access to SIGP Stop-and-Store-Status if live patching is unavailable

The record

In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix IRQ injection with SIGP Stop and Store Status When __inject_sigp_stop() is called for a Stop and Store Status operation, if the vCPU is running, the interrupt is marked as pending and the status is stored by the thread performing the KVM_RUN IOCTL. If the vCPU is already stopped, the status is stored immediately. Storing the status means writing into userspace, which might fault, and __inject_sigp_stop() is called from do_inject_vcpu() which in turn is always called holding a spinlock, which is obviously an issue. Fix this by returning -EWOULDBLOCK from __inject_sigp_stop(), and adding a bool flag to indicate whether a store status is needed. The callers of do_inject_vcpu() are modified to pass the pointer to the bool flag; whenever a Store Status operation is needed, the callers can now perform it outside the spinlock. Opportunistically refactor kvm_s390_set_irq_state() to use scoped_guard() and __free(). [ Added Fixes tag while picking -- Claudio ]

Affected packages

Ecosystem Package Introduced Fixed