CVE-2026-89924 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: Fix old_data leak in guest debug error path
__import_wp_info() allocates a per-watchpoint old_data buffer to back up the original guest memory contents. If a later watchpoint of the same KVM_SET_GUEST_DEBUG request fails to import, kvm_s390_import_bp_data() jumps to the error label, which frees the wp_info array but not the old_data buffers of the entries that were imported successfully. Up to MAX_BP_COUNT - 1 buffers of up to MAX_WP_SIZE bytes are leaked per failed request, and the request can be repeated.
Create error handling for cleaning up all created old_data memory areas.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel's KVM subsystem for s390 architecture contains a resource management flaw within its guest debugging implementation that results in a memory leak under specific failure conditions. This vulnerability is located in the function responsible for importing watchpoint information, specifically when handling requests to set guest debug parameters via the kvm_s390_import_bp_data routine. The core of the issue lies in how temporary buffers are allocated and subsequently freed during the processing of these debugging commands. When a user space application issues a KVM_SET_GUEST_DEBUG request containing multiple watchpoints, the kernel iterates through them to import their configurations. For each successfully imported watchpoint, an old_data buffer is allocated to back up the original guest memory contents associated with that breakpoint. This backup mechanism is critical for maintaining state consistency during debugging operations but introduces complexity in error handling paths.
The technical flaw manifests when a subsequent watchpoint within the same request fails to import due to invalid parameters or other constraints. In this scenario, the execution flow jumps to an error label intended to clean up resources allocated so far. However, the existing cleanup logic only frees the primary wp_info array structure itself but neglects to iterate through and release the individual old_data buffers that were successfully allocated for previously processed watchpoints in that same request sequence. Consequently, every time such a partial failure occurs, memory corresponding to the already-imported watchpoints remains allocated but unreachable by the application or subsequent kernel operations until the entire process terminates. This represents a classic resource leak where dynamic allocations are not matched with deallocations on all execution paths.
From an operational impact perspective, this vulnerability allows for a local denial of service through resource exhaustion. An unprivileged user space process that has access to the KVM device node can repeatedly trigger these failed import scenarios by sending malformed or partially invalid guest debug requests. Each successful partial request leaks up to MAX_BP_COUNT minus one buffers, with each buffer potentially being as large as MAX_WP_SIZE bytes. Since this action can be repeated indefinitely within a single session or across multiple sessions, the cumulative effect is a steady consumption of kernel memory space. Over time, this unbounded allocation depletes available system resources, which can lead to increased swapping pressure, degraded performance for other workloads sharing the same physical memory, and ultimately a system crash if sufficient contiguous free memory cannot be maintained. This aligns with CWE-401, which describes missing release of memory after effective usage, highlighting the failure in proper resource lifecycle management within the kernel's error handling logic.
The remediation strategy involves modifying the error handling path to ensure comprehensive cleanup of all allocated resources before returning control to the caller or propagating the error code upward. The fix requires iterating through any watchpoints that were successfully imported prior to the point of failure and explicitly freeing their associated old_data buffers in addition to the wp_info array. This ensures that no memory is left dangling regardless of where within the request processing sequence an error occurs. By implementing this robust cleanup routine, the kernel prevents the accumulation of unreleased memory blocks during debugging operations. Security practitioners should monitor for updates to the s390 KVM subsystem and apply relevant patches as soon as they become available in their distribution repositories. Additionally, organizations relying on virtualization services with active guest debugging capabilities should ensure that strict access controls are enforced over the /dev/kvm interface to limit exposure to potential attackers who might attempt to exploit this memory leak for denial of service purposes. This issue does not currently appear to be associated with a specific ATT&CK technique as it is primarily a stability and resource management flaw rather than an exploitation vector for privilege escalation or data exfiltration, though the resulting system instability could indirectly facilitate other attack vectors by disrupting security monitoring services.