CVE-2026-46316

What it actually does

This is a race condition in the Linux kernel KVM arm64 virtual GIC ITS translation-cache invalidation path. Multiple invalidation paths can concurrently walk and erase the same xarray cache entry, then incorrectly drop a reference to the iterated pointer rather than only the entry actually removed by xa_erase(). Under the right timing, the cache reference for an IRQ object can be released more than once, allowing the object to be freed while another ITS table entry still references it. The resulting use-after-free can lead to kernel memory corruption, host kernel crash, and potentially code execution or privilege-boundary escape in environments that expose arm64 KVM/vGIC ITS functionality.

Why it matters to the business

Organizations running ARM64 Linux virtualization hosts may face host instability or, in a worst case, compromise of the virtualization boundary between guest workloads and the host kernel. A successful exploit could crash a hypervisor node, disrupt hosted workloads, or allow an attacker with access to create or manipulate KVM guests to gain elevated control over the host. The issue is not currently listed in CISA KEV and has low EPSS with no known public exploit maturity, but the high severity means affected virtualization platforms should still prioritize kernel updates during the next urgent maintenance window.

How an attack unfolds

An attacker needs local access to a system path that can exercise arm64 KVM virtual interrupt-controller behavior, most realistically through a local process with access to KVM device ioctls or through control of a guest/VM configuration that can trigger relevant vGIC ITS activity. The attacker repeatedly induces concurrent invalidation of the same ITS translation-cache entries by racing ITS command handling, GITS_CTLR writes, and redistributor EnableLPIs-clearing paths. Because the vulnerable code can cause multiple threads to drop the same cache-held IRQ reference, the attacker attempts to free an IRQ object while it remains reachable through an ITE mapping. At minimum this can produce a host kernel oops or panic; with reliable heap shaping and timing, the freed memory could potentially be reclaimed with attacker-influenced data to corrupt kernel state and cross the VM-to-host or local-user-to-kernel privilege boundary.

How to fix it

Apply a Linux kernel build that includes the upstream KVM arm64 vgic-its fix changing vgic_its_invalidate_cache() to drop the reference only for the entry actually returned by xa_erase(). Because no specific fixed package versions were provided, use the latest kernel or vendor-supported backport for the affected distribution, appliance, hypervisor, or cloud image. Prioritize ARM64 systems that run KVM guests with virtual GIC ITS/LPI support. If immediate patching is not possible, reduce exposure by restricting access to /dev/kvm and VM-management interfaces, limiting who can create or reconfigure ARM64 KVM guests, disabling or avoiding affected vGIC ITS/LPI features where operationally feasible, and isolating untrusted guest workloads from vulnerable hosts.

How to confirm the fix worked

Confirm that the running kernel includes the vendor backport or upstream fix for the KVM arm64 vgic-its translation-cache invalidation race. Validate both the installed kernel package and the booted kernel version after reboot, since installing a fixed kernel without rebooting leaves the host exposed. On source-based or custom kernels, review the KVM arm64 vgic-its code path and confirm vgic_its_invalidate_cache() only calls vgic_put_irq() for the entry actually removed by xa_erase(), not the pointer produced by xa_for_each() iteration. In operational testing, run representative ARM64 KVM guest workloads using vGIC ITS/LPI functionality and verify there are no kernel oops, KASAN use-after-free reports, or vgic/ITS-related crashes under concurrency stress.

Typical attack path

1. Obtain local execution on an affected ARM64 Linux host or control a workload path that can exercise KVM arm64 vGIC ITS functionality.
2. Create or manipulate a KVM virtual machine using vGIC ITS / LPI-related configuration.
3. Generate high-volume or carefully timed ITS commands and control-register transitions that invalidate the same translation-cache entries from multiple concurrent contexts.
4. Win the race so more than one invalidation path observes the same cache entry and drops the cache reference incorrectly.
5. Trigger use-after-free of an IRQ object that remains mapped by an ITE.
6. Convert the memory corruption into a host crash, denial of service, or potentially kernel-level code execution with sufficient exploitation engineering.

How to detect it

There is no reliable network signature for this vulnerability because exploitation occurs through local kernel/KVM interactions. To assess possible prior exploitation, review ARM64 virtualization hosts for unexplained kernel crashes, oops reports, panic reboots, KASAN/KFENCE memory-safety findings, and logs mentioning KVM arm64 vgic, vgic-its, GIC ITS, LPIs, IRQ reference handling, xarray, or use-after-free around the time of VM creation, shutdown, live migration, interrupt-controller reconfiguration, or high guest interrupt activity. Useful sources include kernel ring buffer logs, persistent journal entries, /var/log/kern.log, /var/log/messages, hypervisor management logs, crash dumps/vmcores, kdump output, and EDR telemetry for local processes opening /dev/kvm or issuing abnormal volumes of KVM ioctls. Absence of these artifacts does not prove non-exploitation, especially if kernel logs are not persistent or crashes were not captured.

• vgic_its_invalidate_cache
• vgic-its
• KVM: arm64
• GICR_CTLR
• GITS_CTLR
• EnableLPIs
• use-after-free
• BUG: KASAN: use-after-free
• kernel BUG
• Unable to handle kernel paging request
• Internal error: Oops
• Kernel panic - not syncing
• /dev/kvm
• /var/crash
• /proc/vmcore

What your security team should do

• Inventory ARM64 Linux systems running KVM virtualization and identify those exposing vGIC ITS/LPI functionality to guest workloads.
• Patch affected kernels using the latest vendor-supported fixed release or backport, then reboot hosts to ensure the fixed kernel is active.
• Prioritize multi-tenant, untrusted-workload, CI, hosting, and edge virtualization environments where guest owners are not fully trusted.
• Restrict /dev/kvm and VM-management API access to trusted administrators and service accounts until patching is complete.
• Monitor for kernel oops, panic, KASAN, or KVM/vgic/ITS-related faults on ARM64 virtualization hosts, especially after unusual VM lifecycle or interrupt-controller activity.
• Because this is not currently KEV-listed and has low EPSS/no known public exploit maturity, treat it as high-impact but not confirmed exploited; focus on exposure reduction and timely patching rather than emergency incident response unless crash evidence exists.