CVE-2026-80548 in Linux
Summary
by MITRE • 08/26/2026
In the Linux kernel, the following vulnerability has been resolved:
s390/vfio_ccw: Selectively expand io_mutex
The io_mutex was defined to serialize the io_regions, but then has also sort of been associated with the I/O themselves because of the close relationship they share.
With the handful of races that are possible, the choices are either to: A) expand the scope of io_mutex to close these remaining windows, or B) reduce the scope of io_mutex to just io_region, and introduce a new lock mechanism for the remaining I/O resources
This patch implements A, since B brings with it a lot more interactions that would need to be tracked and kept in a correct hierarchy. It also takes advantage of the workqueue element for cp_free() that now gets called out of fsm_notoper(), which could be invoked out of an interrupt context and thus cannot acquire a mutex itself.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/26/2026
The Linux kernel vulnerability identified within the s390 vfio_ccw subsystem stems from insufficient synchronization mechanisms governing concurrent access to I/O regions and associated resources. Historically, the io_mutex was designed primarily to serialize operations on io_regions, but due to the tight coupling between these regions and active I/O processes, it inadvertently became a de facto lock for broader I/O activities as well. This implicit association created race conditions where multiple threads or interrupt contexts could access shared state without proper mutual exclusion, leading to potential data corruption or undefined behavior. The core technical flaw lies in the ambiguity of locking scope; while some operations were protected by io_mutex, others fell through the cracks because they occurred outside its critical sections yet still manipulated related resources.
The resolution involves a strategic expansion of the io_mutex's scope to encompass all relevant I/O operations that interact with io_regions, thereby closing these remaining concurrency windows. This approach was chosen over introducing a separate lock mechanism for individual I/O resources because managing multiple locks would require establishing and maintaining a strict hierarchy to prevent deadlocks, which introduces significant complexity and potential for new errors. By expanding the existing mutex, developers ensure that all critical sections involving io_regions are protected under a single synchronization primitive, simplifying the locking logic while effectively eliminating the race conditions. This change aligns with best practices in concurrent programming by ensuring consistent lock ordering and reducing the surface area for concurrency bugs.
From an operational perspective, this vulnerability could allow local attackers to trigger race conditions that may lead to kernel instability, denial of service, or potentially privilege escalation if memory corruption occurs due to unsynchronized access. The impact is particularly relevant on s390 architectures where virtualization functions rely heavily on precise timing and state management for device emulation. The fix ensures that even when operations are invoked from interrupt contexts via workqueue elements like cp_free(), the necessary synchronization is maintained, preventing issues arising from non-mutex-safe calls in atomic context. This enhances system stability and security by guaranteeing data integrity during high-concurrency scenarios typical of virtualized environments.
This vulnerability maps to CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'), as the root cause is the failure to properly synchronize access to shared resources in a multi-threaded or interrupt-driven environment. In terms of MITRE ATT&CK, this relates to techniques involving resource manipulation that could be exploited for denial-of-service attacks against virtualization infrastructure. Mitigation strategies include applying the kernel patch that expands io_mutex scope and ensuring systems are updated with the latest stable Linux releases containing these fixes. Additionally, developers should audit similar subsystems for implicit locking assumptions and enforce explicit synchronization primitives where race conditions might exist, adhering to principles of least privilege and defense in depth within kernel development practices.