Description

In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Limit the number of channel program segments The processing of channel programs, and the CCWs within them, is done recursively. As such, there is an arbitrary (but not architectural) limit to the number of CCWs that can exist in a single channel program. The vfio-ccw logic breaks these channel programs into segments whenever it encounters a Transfer-In-Channel (TIC) CCW, and the combined number of segments count towards the global limit. Impose an equivalent limit to the number of segments until such logic can be made non-recursive.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.3",
  "pubDate": "2026-08-26T15:17:09.990Z",
  "pubdate": "2026-08-26T15:17:09.990Z",
  "executiveSummary": "The vulnerability identified in the Linux kernel s390/vfio_ccw subsystem pertains to unbounded recursion during the processing of channel programs.\nThis flaw allows an attacker to potentially trigger a kernel stack overflow by crafting malicious channel programs with an excessive number of segments.\nThe affected product is the Linux kernel, specifically the vfio_ccw driver responsible for facilitating I/O operations for s390 architecture devices.\nThe risk implication is a potential denial-of-service (DoS) condition via kernel panic or system instability caused by exhausted stack memory.\nExploitation requires the attacker to possess the capability to interact with the vfio-ccw interface, typically requiring sufficient privileges to manage or assign vfio devices to a guest environment.\nThe primary mitigation is to enforce an architectural constraint on the number of channel program segments, thereby preventing the recursive processing logic from exceeding stack limits.",
  "technicalDetails": "The vulnerability resides within the s390 vfio_ccw driver, which handles I/O control blocks (CCWs) passed from userspace to the hardware.\nThe kernel processes these channel programs recursively, traversing the chain of CCWs. When a Transfer-In-Channel (TIC) CCW is encountered, the driver treats the referenced address as a new segment and recurses to process the subsequent chain.\nThe root cause is the lack of a defined, global limit on the number of segments a single channel program can contain. Because the implementation relies on recursive function calls to traverse these segments, each segment adds a frame to the kernel stack.\nAn attacker can construct a deeply nested or excessively long series of channel program segments utilizing TIC CCWs. By forcing the kernel to recurse beyond its allocated stack size, the attacker triggers a stack overflow. This leads to memory corruption, where the kernel stack overwrites adjacent kernel memory, resulting in an immediate kernel panic.\nThe attack flow involves the following steps: 1) The attacker allocates a vfio_ccw device within a controlled guest or process. 2) The attacker submits a specially crafted channel program containing an arbitrary number of linked CCW segments via the VFIO_DEVICE_CCW_IOCTL or equivalent interface. 3) The kernel's recursive processing function is invoked for each segment. 4) The cumulative stack frames generated by the excessive depth of the recursive calls exceed the thread's stack capacity. 5) The system triggers an unrecoverable exception, leading to a system crash.\nThis vulnerability is particularly concerning in virtualized environments where userspace applications (such as QEMU/KVM) provide the CCW structures to the host kernel. While not directly network-exposed in many cases, it poses a significant risk to the host integrity from a compromised or malicious guest instance. Because the current processing logic is inherently recursive and non-iterative, there is no inherent mechanism to bail out before the stack overflow occurs. The remediation involves imposing an explicit, architectural limit on the segment count, ensuring that the depth of recursion remains within the bounds of the kernel stack, thereby neutralizing the potential for exploitation until the logic can be fully refactored into an iterative approach."
}