CVE-2026-80555 in Linux
Summary
by MITRE • 08/26/2026
In the Linux kernel, the following vulnerability has been resolved:
s390/vfio_ccw: Free all memory if cp_init() fails
The routine cp_free() is called to unpin/free any memory once an I/O is completed successfully, or if cp_prefetch() fails. But if cp_init() fails, and cp->initialized is not enabled, the same routine cannot be used to free all the memory.
An attempt to address this exists in ccwchain_handle_ccw(), where a single call to ccwchain_free() is made for the currently-processed CCW segment. But this will leak other segments (created as a result of a Transfer in Channel) that had been allocated as part of the same channel program.
Address this by performing the cleanup outside of the recursive ccwchain_handle_ccw()/ccwchain_loop_tic() logic.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/26/2026
The Linux kernel vulnerability identified within the s390 vfio_ccw subsystem represents a critical resource management flaw rooted in improper error handling during channel program initialization. The core issue arises from an asymmetry in memory lifecycle management where the standard cleanup routine, cp_free(), is designed to unpin and release memory only after successful I/O completion or upon failure of the prefetch operation. However, when the initial setup function cp_init() fails before marking the control block as initialized via the cp->initialized flag, this specific deallocation path becomes inaccessible. This architectural oversight means that any memory allocated during the initialization phase remains orphaned in kernel space because the conditional logic prevents the execution of the necessary cleanup procedures for resources acquired prior to successful state establishment.
This defect leads directly to a persistent resource leak within the hypervisor interface layer. Specifically, while there is an existing mitigation attempt located in ccwchain_handle_ccw() that invokes ccwchain_free(), this approach is fundamentally insufficient due to its scope limitation. The function only releases memory associated with the currently processed Channel Command Word segment. It fails to account for additional segments allocated dynamically through Transfer in Channel operations within the same channel program. Consequently, these secondary allocations are never freed when initialization errors occur, resulting in a gradual depletion of kernel virtual address space and physical memory over time as affected devices undergo repeated failed initialization attempts or error conditions.
From a security perspective, this vulnerability aligns with CWE-401, which describes missing release of memory after successful allocation. In the context of long-running systems such as those utilizing IBM mainframe architectures via VFIO CCW, these leaks can escalate into Denial of Service scenarios by exhausting available kernel memory resources. The lack of comprehensive cleanup during error paths allows attackers or malfunctioning guest operating systems to trigger repeated initialization failures, thereby accelerating resource exhaustion and potentially destabilizing the host system or other co-located virtual machines sharing those physical resources.
The remediation strategy involves restructuring the control flow to perform necessary cleanup operations outside of the recursive logic governing ccwchain_handle_ccw() and ccwchain_loop_tic(). By decoupling the error handling path from the iterative processing loop, developers ensure that all allocated segments, including those created via Transfer in Channel instructions, are properly released regardless of where within the initialization sequence a failure occurs. This approach enforces strict adherence to resource acquisition is initialization principles by guaranteeing that every allocation has a corresponding deallocation path under both success and failure conditions, thereby restoring memory integrity and preventing future leaks associated with this subsystem.