CVE-2026-98470: KVM: arm64: Don't WARN on an unknown VM ioctl in protected mode
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Don't WARN on an unknown VM ioctl in protected mode
kvmpkvmioctlallowed() WARNs when kvmgetcapforkvmioctl() doesn't find the ioctl number in vmioctlcaps[], and kvmarchvmioctl() calls it for every number the generic code doesn't handle, so ioctl(vmfd, 0xdeadbeef) from userspace taints a pKVM host and panics it under paniconwarn. The lookup is fed userspace input: return false, and userspace gets the -EINVAL kvmarchvmioctl() returns for that number on a host without pKVM.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1
Event History
Frequently Asked Questions
Which systems are exposed to a host panic?
The issue affects arm64 KVM hosts using protected KVM (pKVM) when panic_on_warn is enabled. On such hosts, an unknown VM ioctl can taint the host and cause a panic.
What access does an attacker need to trigger the issue?
An attacker needs userspace access sufficient to issue an ioctl against a KVM VM file descriptor. The triggering ioctl number is userspace-controlled and does not need to be a recognized KVM VM ioctl.
What happens on hosts that do not use pKVM?
For an unknown VM ioctl, the expected result is -EINVAL from kvm_arch_vm_ioctl(). The described WARN and resulting panic scenario is specific to protected mode.
What is the immediate mitigation if the fix cannot be deployed?
Avoid enabling panic_on_warn on affected pKVM hosts, as this is what turns the WARN condition into a host panic. Restrict untrusted userspace access to KVM VM file descriptors where possible.