CVE-2026-98474 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
s390/pci: Fix missing device lock in zpci_report_status()
When pdev is non-NULL, zpci_report_status() accesses the device's driver. To get a consistent state matching the recovery, the device lock needs to be held. Do so by expanding the existing device lock critical section.
The lock only needs to be held when the pdev is non-NULL, so extract the pdev-specific reporting into a helper function which also adds a lockdep assertion to detect calls without the device lock held.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel vulnerability identified in the s390 PCI subsystem involves a missing device lock acquisition within the zpci_report_status() function. This issue arises specifically when the pci_dev pointer, referred to as pdev, is not null, indicating that an active device driver instance exists and requires access. The core technical flaw lies in the fact that accessing the device's driver state without holding the appropriate synchronization primitive can lead to race conditions or inconsistent states during critical operations such as recovery procedures. In concurrent systems, particularly those involving hardware interaction like PCI devices on IBM s390 architecture, maintaining a consistent view of device status is paramount for system stability and data integrity. Without proper locking mechanisms in place, multiple threads or interrupt handlers might attempt to modify or read the driver's internal state simultaneously, resulting in undefined behavior that could manifest as crashes, corrupted memory structures, or incorrect reporting of hardware status.
From an operational perspective, this vulnerability poses a risk primarily during device recovery scenarios where timely and accurate communication between the kernel and the PCI device is essential. If the zpci_report_status() function executes without the necessary lock, it may read stale data or overwrite concurrent updates made by other parts of the driver stack. This inconsistency can prevent proper failover mechanisms from functioning correctly, potentially leading to service interruptions for applications relying on these devices. Furthermore, in high-throughput environments where PCI device status changes frequently, such race conditions could exacerbate performance degradation due to repeated retries or error handling overhead triggered by corrupted state information. The absence of synchronization also undermines the reliability of diagnostic tools that depend on accurate real-time reporting from kernel subsystems.
To address this issue, developers have implemented a fix that expands the existing device lock critical section within zpci_report_status() to encompass all accesses related to non-null pdev instances. This ensures that any interaction with the driver's state is serialized and protected against concurrent modifications. Additionally, the solution involves refactoring the code by extracting pdev-specific reporting logic into a dedicated helper function. This structural change not only clarifies the scope of locking requirements but also facilitates better maintainability. Crucially, this helper function includes lockdep assertions designed to detect any future calls that might occur without holding the device lock. Lockdep is a dynamic debugging mechanism in the Linux kernel that validates proper usage of locks and helps prevent deadlocks or missing-lock scenarios during development and testing phases, thereby serving as an early warning system for similar concurrency bugs before they reach production environments.
This vulnerability aligns with CWE-362, which describes concurrent execution using shared resources with improper synchronization. The lack of a mutex or spinlock around critical sections accessing shared driver state is a classic example of this class of weakness. By enforcing strict lock acquisition protocols and integrating automated detection via lockdep, the fix mitigates the risk associated with race conditions in kernel-space code. From an ATT&CK perspective, while this specific issue does not directly facilitate initial access or privilege escalation by external attackers, it impacts system availability and integrity, which are key components of the CIA triad often targeted in denial-of-service attacks or exploitation chains aiming to destabilize infrastructure. Proper synchronization ensures that even under heavy load or during fault recovery, the kernel maintains predictable behavior, thereby preserving the overall security posture of the operating system by preventing potential crashes that could be leveraged for further compromise if they lead to memory corruption exploitable via other vectors.