CVE-2026-89920: KVM: s390: Fix memory corruption by not reinjecting CK machine checks
In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: Fix memory corruption by not reinjecting CK machine checks
Channel-subsystem damage machine checks are for the host channel subsystem. The guest channel subsystem is emulated in the userspace VMM. There is no point in forwarding such machine checks into the guest.
This also simplifies the machine check reinjection and avoids kfree of a stack variable as reported by sashiko. There might be still machine checks that have the ck bit set with another bit (like instruction damage), mask out the CK bit in s390backupmcckinfo(), like the CP and ED bits already are.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Fix memory corruption by not reinjecting CK machine checks: in s390_backup_mcck_info(), mask out the CK bit so such machine checks are not forwarded/reinjected into the guest channel subsystem.
Linux kernel (KVM: s390) CK bit handling in s390_backup_mcck_info() = mask out the CK bit
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
The issue is in the Linux kernel's KVM implementation for s390. It concerns handling of channel-subsystem damage machine checks in virtualized s390 environments.
What condition triggers the memory-corruption path?
The affected path involves reinjection of channel-subsystem damage machine checks into a guest. Such checks belong to the host channel subsystem, while the guest channel subsystem is emulated by the userspace VMM.
Are machine checks with the CK bit always dropped by the fix?
No. A machine check can have the CK bit set alongside another condition, such as instruction damage. The fix masks out the CK bit during backup of machine-check information, similarly to the existing handling of CP and ED bits.