CVE-2026-98652 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: Add missing srcu in kvm_s390_set_irq_state()
Like kvm_s390_inject_vcpu(), kvm_s390_set_irq_state() also needs the kvm->srcu or the slots lock when performing the Store status operation.
Fix by taking kvm->srcu in kvm_s390_set_irq_state().
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel's KVM subsystem for the s390 architecture contains a concurrency vulnerability within the kvm_s390_set_irq_state function that arises from improper synchronization during interrupt state management. This specific flaw represents a classic race condition where critical data structures are accessed without holding the necessary read-side locks, specifically the source code update (SRCU) lock associated with the KVM instance. In virtualized environments, particularly those utilizing IBM System z hardware emulation, maintaining consistency between host kernel states and guest vCPU states is paramount for system stability. The kvm_s390_set_irq_state function is responsible for modifying interrupt state information, which involves operations that may interact with memory regions or data structures protected by SRCU to prevent use-after-free scenarios or inconsistent reads during concurrent modifications.
The technical root cause of this vulnerability lies in the omission of acquiring the kvm->srcu lock before performing store status operations within the function. While a similar function, kvm_s390_inject_vcpu(), correctly implements these synchronization primitives, kvm_s390_set_irq_state() was left without such protection. This inconsistency creates a window where another thread or interrupt handler could modify the underlying data structures while kvm_s390_set_irq_state is reading or writing to them. The Store Status operation itself requires accessing memory that might be reallocated or freed by other kernel threads, making the absence of SRCU particularly dangerous as it can lead to dereferencing invalid pointers or reading stale data.
From a security and operational impact perspective, this vulnerability allows for potential denial of service through kernel crashes or panics if an attacker can trigger concurrent access patterns that exploit the race condition. In more severe scenarios involving sophisticated exploitation techniques, such memory corruption issues could potentially be leveraged to achieve arbitrary code execution within the host kernel context, thereby compromising the isolation between virtual machines and gaining control over the underlying physical hardware resources. The lack of proper locking mechanisms undermines the integrity guarantees provided by the KVM subsystem, making it a significant risk for multi-tenant cloud environments where multiple guests share the same hypervisor instance.
This issue aligns with Common Weakness Enumeration (CWE) category CWE-362, which describes concurrent execution using shared resources with improper synchronization. Furthermore, in the context of the MITRE ATT&CK framework, this type of vulnerability facilitates privilege escalation and defense evasion by allowing an attacker to manipulate kernel state through race conditions, potentially bypassing security controls that rely on consistent system states. The fix involves integrating kvm->srcu acquisition into kvm_s390_set_irq_state(), ensuring that all accesses to shared KVM data structures are properly serialized or protected against concurrent modification.
To mitigate this vulnerability and similar issues in the future, developers must ensure strict adherence to locking protocols when accessing shared kernel resources within virtualization layers. Regular code audits focusing on concurrency patterns and synchronization primitives are essential for maintaining system integrity. Administrators should apply the latest kernel updates that include this patch immediately to close the window of exposure. Additionally, implementing static analysis tools capable of detecting missing lock acquisitions in concurrent code paths can help prevent such oversights during development cycles, ensuring robust protection against race condition exploits across all KVM subsystems.