CVE-2026-64106

What it actually does

This is an improper input validation flaw in the Linux kernel KVM implementation for ARM64 virtual Generic Interrupt Controller ITS state restore. During virtual machine state restoration, userspace can provide an ITS Device Table Entry whose Size field encodes more EventID bits than the virtual ITS supports. The normal live MAPD path rejects this state, but the restore path previously accepted it and stored an out-of-range value in the virtual device structure. That unchecked value can later be used to compute an oversized scan range in vgic_its_restore_itt(), potentially causing host kernel memory over-read, excessive scanning, kernel crash, or other host-kernel-side failure conditions. The primary impacts are host availability loss and possible exposure of host memory contents; integrity impact is not indicated by the supplied metadata.

Why it matters to the business

Organizations running ARM64 Linux virtualization hosts with KVM may be exposed to host-level disruption or potential data exposure if malicious or untrusted VM restore state is processed. In practical terms, a compromised local virtualization component, malicious VM migration stream, or untrusted snapshot/restore workflow could crash a host or potentially expose sensitive host memory. Although EPSS is currently low, the CVSS score is high and the issue affects a privileged virtualization boundary, so ARM64 KVM hosts that process externally supplied or tenant-controlled VM state should be prioritized for remediation.

How an attack unfolds

An attacker needs local ability to influence KVM VM state restoration on an ARM64 host, such as by controlling a VMM process, supplying a malicious migration stream, or causing a restore operation to consume crafted virtual ITS device state. The attacker crafts an ITS Device Table Entry with a Size value that represents more EventID bits than the virtual ITS supports. Because the vulnerable restore path does not enforce the same bounds check used by the live MAPD path, KVM accepts the invalid value and stores it in the virtual device state. When KVM later restores or scans the interrupt translation table, the out-of-range EventID bit count can be converted into an oversized table scan range. This can trigger abnormal kernel behavior, including host kernel crashes or potential host memory exposure. There is no supplied evidence of known exploitation, ransomware use, or inclusion in the CISA KEV catalog.

How to fix it

Apply a Linux kernel update that includes the KVM ARM64 vgic-its fix rejecting restored Device Table Entries where num_eventid_bits exceeds VITS_TYPER_IDBITS. No exact fixed package versions were provided in the input, so validate through the operating system vendor advisory, kernel changelog, or source patch reference for the change titled "KVM: arm64: vgic-its: Reject restored DTE with out-of-range num_eventid_bits." Prioritize ARM64 virtualization hosts using KVM, especially systems that support live migration, VM snapshot import, restore from external sources, or multi-tenant VM management. As interim mitigations, restrict access to /dev/kvm and VM management interfaces to trusted administrators and trusted service accounts only; do not import or restore VM snapshots, migration streams, or state files from untrusted sources; isolate or disable restore/migration features where untrusted users can influence VM state; and consider temporarily moving high-risk ARM64 KVM workloads to patched hosts.

How to confirm the fix worked

Confirm that ARM64 KVM hosts are running a kernel build containing the bounds check in vgic_its_restore_dte() that rejects restored DTEs with num_eventid_bits greater than VITS_TYPER_IDBITS. Validate through package manager metadata, vendor errata, kernel changelogs, or source inspection if building kernels internally. For source validation, confirm the restore path mirrors the MAPD validation behavior before device allocation. Operationally, verify that vulnerable hosts have been rebooted into the patched kernel, not merely updated on disk. Exposure can be assessed by identifying ARM64 systems with KVM enabled, /dev/kvm present, and virtualization stacks such as QEMU/libvirt that support migration or snapshot restore. Where safe, use vendor-provided regression tests or a controlled negative test to confirm malformed restored ITS state is rejected rather than accepted or causing kernel instability.

Typical attack path

1. Gain local ability to interact with KVM VM restore functionality on an ARM64 Linux host, directly or through a compromised VMM, migration, or snapshot restore workflow.
2. Prepare a crafted virtual ITS Device Table Entry with a Size field that encodes more EventID bits than the virtual ITS supports.
3. Trigger VM state restore so the malformed DTE is processed by the vulnerable vgic_its_restore_dte() path.
4. Cause the invalid num_eventid_bits value to be stored in KVM virtual interrupt controller device state.
5. Trigger subsequent ITS interrupt translation table restoration or scanning that uses the unchecked value to create an oversized scan range.
6. Leverage the resulting condition to crash the host kernel, disrupt running workloads, or potentially expose host memory contents.

How to detect it

This flaw is unlikely to produce a clean application-level indicator and may only be visible through virtualization activity followed by kernel warnings, oopses, panics, host resets, or crash dumps. Review kernel logs, persistent journald logs, hypervisor/VMM logs, libvirt logs, QEMU logs, audit logs for /dev/kvm access, VM migration logs, and host crash dumps. Focus on events where VM restore, incoming migration, snapshot import, or virtual interrupt controller state restoration occurred shortly before a kernel fault. In crash dumps or stack traces, look for KVM ARM64 VGIC ITS functions such as vgic_its_restore_dte(), vgic_its_restore_itt(), and scan_its_table(). Investigate unusual local processes opening /dev/kvm, unexpected qemu-system-aarch64 invocations, failed or repeated migration/restore attempts, and host crashes isolated to ARM64 KVM workloads. There are no known network indicators, ransomware indicators, or named threat actor artifacts supplied for this vulnerability.

• vgic_its_restore_dte
• vgic_its_restore_itt
• scan_its_table
• KVM: arm64
• vgic-its
• VITS_TYPER_IDBITS
• num_eventid_bits
• /dev/kvm
• qemu-system-aarch64
• kernel: Oops
• kernel panic
• BUG: kernel NULL pointer dereference
• Unable to handle kernel
• libvirtd
• virtqemud
• incoming migration
• restore domain
• snapshot restore

What your security team should do

• Inventory ARM64 Linux hosts running KVM and prioritize systems that support VM migration, snapshot restore, or externally supplied VM state.
• Patch affected hosts to a kernel containing the vgic-its restored DTE bounds-check fix, then reboot into the patched kernel.
• Restrict /dev/kvm access and virtualization management APIs to trusted users and service accounts only.
• Temporarily block or tightly control VM restore, snapshot import, and live migration from untrusted or cross-boundary sources until hosts are patched.
• Review recent host kernel logs for KVM, vgic, ITS, oops, panic, or crash traces around VM restore or migration activity.
• Correlate libvirt/QEMU migration and restore events with kernel instability to identify possible attempted exploitation.
• Ensure host crash dump collection, kernel audit logging, and virtualization management logs are retained long enough to investigate pre-patch activity.
• Treat unexplained ARM64 KVM host crashes during VM restore or migration as potentially security-relevant until ruled out.