CVE-2026-89923: KVM: s390: Free guest debug data on vcpu destroy
In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: Free guest debug data on vcpu destroy
kvms390clearbpdata() is only called from kvmarchvcpuioctlsetguestdebug(), 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 hwbpinfo, hwwpinfo and all olddata buffers, since generic KVM frees the vCPU right after kvmarchvcpudestroy().
That is bounded by MAXBPCOUNT entries, so roughly 8 KiB per vCPU, but it is unbounded over VM lifetimes. The allocations are GFPKERNELACCOUNT, 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 kvmvcpu is zero allocated, so for a vCPU that never enabled debugging the counters are 0 and the pointers NULL.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this leak?
The issue affects Linux kernel KVM on s390 when a vCPU has guest debugging enabled with hardware breakpoints or watchpoints armed. vCPUs that never enabled debugging do not retain these debug-data allocations.
What event triggers the memory leak?
The leak occurs when a vCPU is destroyed while hardware breakpoints remain armed, such as when a VMM exits or crashes without first changing or disabling guest debugging. The affected debug data was previously cleared only when userspace changed or disabled debugging.
What is the practical impact?
The leak is bounded to roughly 8 KiB per affected vCPU, but can grow without bound across VM lifetimes. Because the allocations are accounted memory, their charges can outlive the exiting process and keep dying memory cgroups pinned.
How can I tell whether a workload is affected?
A workload is affected if it creates s390 KVM vCPUs, enables guest debugging with hardware breakpoints or watchpoints, and destroys those vCPUs without first disabling or changing debugging. The normal shutdown or crash path for a VMM can meet these conditions.
What can be done before applying the fix?
Ensure userspace disables or changes guest debugging before destroying vCPUs so the existing debug-data cleanup path runs. This reduces exposure for VMMs that use hardware breakpoint or watchpoint debugging.