CVE-2026-89923 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: Free guest debug data on vcpu destroy
kvm_s390_clear_bp_data() is only called from kvm_arch_vcpu_ioctl_set_guest_debug(), i.e. when user space changes or disables debugging. A vCPU that is destroyed while hardware breakpoints are still armed - the normal case when the VMM just exits or crashes - leaks hw_bp_info, hw_wp_info and all old_data buffers, since generic KVM frees the vCPU right after kvm_arch_vcpu_destroy().
That is bounded by MAX_BP_COUNT entries, so roughly 8 KiB per vCPU, but it is unbounded over VM lifetimes. The allocations are GFP_KERNEL_ACCOUNT, so the charge also outlives the exiting process and pins dying memcgs.
Fix by clearing the debug data on vCPU destruction. Calling it unconditionally is fine: struct kvm_vcpu is zero allocated, so for a vCPU that never enabled debugging the counters are 0 and the pointers NULL.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/16/2026
The Linux kernel's KVM subsystem for IBM Z architecture contains a resource management flaw related to guest debug data handling during virtual CPU lifecycle transitions. Specifically, the function kvm_s90_clear_bp_data is responsible for releasing hardware breakpoint information structures including hw_bp_info and hw_wp_info as well as associated old_data buffers. This cleanup routine was previously invoked exclusively from kvm_arch_vcpu_ioctl_set_guest_debug which triggers when user space applications modify or disable debugging configurations. Consequently, if a virtual CPU is destroyed while hardware breakpoints remain armed the system fails to release these memory allocations resulting in a kernel memory leak that persists beyond the lifetime of the exiting process and continues to charge against the memory control group even after the associated vCPU has been deallocated by generic KVM cleanup routines.
This vulnerability represents an unbounded resource consumption scenario where each affected virtual CPU can retain approximately eight kilobytes of kernel memory depending on the maximum breakpoint count configuration limits. While individual leaks are small in isolation they accumulate over time particularly in environments with high churn rates for virtual machines or long-running systems that frequently create and destroy vCPUs without properly resetting debug states prior to termination. The persistent charging against memory control groups can lead to premature exhaustion of available memory resources effectively pinning dying memory cgroups and potentially causing denial of service conditions for other workloads sharing the same resource constraints within the host system infrastructure.
From a classification perspective this issue aligns with CWE-401 which describes missing release of memory after successful allocation leading to information leakage or resource consumption issues commonly referred to as memory leaks in kernel space contexts. The attack vector typically involves creating virtual machines that utilize hardware debugging features and then abruptly terminating them without properly disabling those debug states thereby triggering the incomplete cleanup path within the KVM architecture layer for s390 processors. This behavior allows an unprivileged user or compromised guest administrator with access to vCPU management interfaces to gradually degrade host system stability through cumulative memory pressure rather than exploiting a direct code execution flaw.
Mitigation strategies should prioritize applying vendor-provided kernel patches that update the kvm_arch_vcpu_destroy implementation for s390 architectures to include unconditional calls to clear breakpoint data structures regardless of whether debugging was previously enabled by user space applications. System administrators operating affected systems can implement operational controls such as ensuring graceful shutdown procedures for virtual machines that explicitly disable hardware breakpoints before vCPU destruction occurs through hypervisor management tools. Additionally monitoring memory control group usage patterns and setting appropriate limits on per-vcpu debug resource allocations can help contain the impact of this vulnerability until permanent fixes are deployed across all relevant kernel versions in production environments.