CVE-2026-80549 in Linux
Summary
by MITRE • 08/26/2026
In the Linux kernel, the following vulnerability has been resolved:
s390/vfio_ccw: Move cp cleanup out of not operational
The fsm_notoper() routine is called when the device has been lost, and is (by definition) no longer operational. Since this can happen asynchronously from the normal behavior of the driver, the cleanup may happen when holding other locks in the calling sequence (notably, the cio subchannel lock).
Push the cleanup of the private->cp resources to a workqueue, where it can be done out from under that lock sequence and a future patch can safely manage the locking requirements.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/26/2026
The vulnerability described involves a concurrency issue within the Linux kernel's s390 VFIO CCW driver, specifically concerning the handling of channel programs during device state transitions. The core technical flaw lies in the execution context of the fsm_notoper routine, which is invoked when a virtual function I/O control unit has been lost and is deemed no longer operational. Because this event can occur asynchronously relative to the normal operation flow of the driver, there is a risk that the cleanup of private channel program resources may be executed while holding critical locks from other parts of the subsystem, most notably the cio subchannel lock. This creates a potential for deadlocks or race conditions if subsequent operations attempt to acquire these same locks in an incompatible order or context, violating standard locking hierarchies and potentially leading to system instability or denial of service through kernel hangs.
From a technical perspective, this issue represents a classic case of improper synchronization within asynchronous event handling paths. When the device is lost, the driver must clean up associated resources such as channel programs (cp) allocated for communication with the hardware. Performing this cleanup directly in the context where locks are already held can lead to recursive locking scenarios or priority inversion if other threads attempt to access the same subchannel structures simultaneously. The original implementation did not account for the complexity of lock dependencies that might arise from asynchronous device removal events, thereby exposing the system to stability risks under specific timing conditions involving concurrent I/O operations and device state changes.
The operational impact of this vulnerability is primarily related to system reliability rather than direct security exploitation by external actors. However, kernel-level deadlocks or crashes can result in a denial of service for all workloads running on the affected s390 architecture systems. In virtualized environments utilizing VFIO CCW, such instabilities could disrupt multiple guest operating systems sharing the underlying hardware resources, leading to significant downtime and potential data loss if transactions are interrupted mid-execution due to kernel panics or unresponsive subsystems. This aligns with CWE-824, which covers access of a resource after it has been freed, although in this specific instance, the primary concern is more accurately aligned with concurrency issues such as race conditions or improper locking sequences that compromise system integrity.
To mitigate this vulnerability, the fix involves refactoring the cleanup logic to defer the release of private channel program resources until they can be safely executed outside of any holding lock sequence. By pushing the cleanup task to a workqueue, the kernel ensures that the resource deallocation occurs in a controlled context where locking requirements are properly managed and do not conflict with other subsystem operations. This approach decouples the asynchronous device loss event from the immediate critical sections protected by subchannel locks, thereby eliminating the potential for deadlock scenarios. System administrators should ensure their kernels are updated to include this patch, which addresses the synchronization flaw without requiring changes to application-level configurations or hardware settings.
This remediation strategy reflects best practices in kernel development regarding asynchronous processing and resource management. It aligns with ATT&CK technique T1499, specifically endpoint denial of service via system instability caused by software vulnerabilities that lead to crashes or hangs. By ensuring that cleanup operations are serialized through a workqueue rather than executed inline during lock-held states, the driver maintains robustness against race conditions inherent in asynchronous hardware event handling. This structural change enhances the overall resilience of the s390 VFIO CCW subsystem, preventing potential denial-of-service scenarios arising from internal kernel synchronization failures while maintaining compliance with secure coding standards for concurrent systems programming.