ITScape — KVM/arm64 guest-to-host escape tracking

This tracker is no longer updated. Every tracked distribution has shipped a kernel carrying the fix or was never affected.

Summary

How the exploitation chain works

ITScape is a use-after-free in KVM/arm64’s vGIC-ITS (Interrupt Translation Service) emulation. vgic_its_invalidate_cache() walks the per-ITS translation cache with xa_for_each() and drops the cache’s reference on each entry with vgic_put_irq() — but it puts the iterated pointer rather than the value returned by xa_erase().

The function runs from contexts that do not exclude one another: the ITS command handlers hold its_lock, the GITS_CTLR write path holds cmd_lock, and the path that clears EnableLPIs in a redistributor’s GICR_CTLR holds neither. Two or more can drain the same cache concurrently; if each observes the same entry, erases it, and then puts it, the single reference the cache holds is dropped more than once. The vgic_irq can then be freed while an ITE still maps it — a use-after-free.

A guest with EL1 (guest-kernel) privilege triggers this by driving the relevant interrupt-related ITS operations to race the invalidation paths. Because the bug is in in-kernel KVM rather than QEMU userspace, a successful exploit runs with host-kernel privilege — not the privilege of a userspace VMM process. The PoC, built on the kernel’s own KVM selftest, escapes the guest and creates /ITScape on the host.

ℹ️ ITScape is arm64-only — it lives in the GICv3/4 ITS emulation that x86 KVM does not have. The x86 KVM escape by the same researcher is a different bug, Januscape. Triggering ITScape needs guest root/EL1; there is no clean runtime mitigation knob, so the kernel backport is the only thing that flips a verdict here.

Vulnerable commit range

The reachable lifetime is therefore v6.10 through v7.0; kernels older than 6.10 never had the buggy rework and are not affected. This is a much narrower window than the x86 Januscape sibling, whose bug dates to 2010.

Upstream fixed versions

The fix landed in v7.1 and the kernel CNA (CVE-2026-46316) backported it to every maintained in-window stable line: 6.12.93, 6.18.35, and 7.0.12. The pre-6.10 longterm lines (6.6.y, 6.1.y, 5.15.y, 5.10.y) predate the introducing commit and are not affected.

The short-lived 6.10.y / 6.11.y stable branches were in-window but reached end of life; when verifying a tree directly, the fixed function is vgic_its_invalidate_cache() in arch/arm64/kvm/vgic/vgic-its.c.

Distribution status

The deciding fact per release is whether the arm64 kernel is in the 6.10–7.0 window and lacks the 13031fb6b835 backport. A kernel older than 6.10, or carrying the fix, is not exploitable. Fixed since records the date the kernel fix first lands in that release.

The rows below track the arm64 builds of a focused set of distributions. Proxmox VE is x86-only and therefore does not appear here — its KVM exposure is covered by the Januscape tracker. Other systems named in the disclosures appear only in prose where relevant.

Debian

Debian’s arm64 linux is affected only from 6.10 on. sid (7.1.3-1, carries the fix) and forky (testing, 7.0.13-1 ≥ the first-fixed 7.0.12) are fixed. trixie stable received 6.12.95-1 via trixie-security (DSA-6355-1); since 6.12.95 ≥ 6.12.93 it carries the backport — trixie is now fixed. bookworm (6.1) and bullseye (5.10) predate the v6.10 trigger and are not affected.

NixOS

The default linuxPackages (linux_6_18) on both nixos-unstable and nixos-26.05 is 6.18.38, which carries the 13031fb6b835 backport (6.18.38 ≥ 6.18.35) on aarch64 as on x86; linuxPackages_latest (linux_7_1) is 7.1.3. Both channels are fixed.

Rocky Linux / RHEL family

On arm64, EL10 (the 6.12-based el10 kernel) is in the ITScape window — but so is EL9: Red Hat backported the vGIC-ITS code into its el9 5.14 kernel, so RHEL/Rocky 9 carry the bug despite the 5.14 base (this is why a version-only “predates 6.10” check is wrong for EL — only EL8’s 4.18 genuinely predates the code). Red Hat fixed RHEL 10 in RHSA-2026:34911 (6.12.0-211.30.1.el10_2) and RHEL 9 in RHSA-2026:36018 (5.14.0-687.22.1.el9_8). Rocky landed the corresponding rebuilds on 2026-07-11: Rocky 9 via RLSA-2026:36018 (5.14.0-687.22.1.el9_8) and Rocky 10 via RLSA-2026:36956 (6.12.0-211.32.1.el10_2, which subsumes the 211.30.1 fix). RHEL 8 / Rocky 8 (4.18) are not affected; Oracle Linux and CloudLinux OS track RHEL.

Amazon Linux

Each Amazon kernel stream is a row above. AL2023’s default kernel (6.1) and all of AL2 (4.14 / 5.10 / 5.15) predate v6.10 and are not affected; only AL2023’s opt-in kernel6.12 / kernel6.18 streams are in-window, and both have been fixed (ALAS2023-2026-1894 / -1881, 2026-06-22, with matching livepatch updates). Status verified from the repodata updateinfo.xml, not the JS-rendered per-CVE ALAS pages.

Detection

Is this an arm64 host? ITScape is arm64-only; aarch64 output means the arch is in scope (x86 hosts are not affected):

uname -m

Is the running kernel in the affected window and missing the fix? The bug is reachable on 6.10 through 7.0; compare the running kernel against the Upstream fixed versions table and your distro row above:

uname -r

Is this a KVM host? The bug is in the host’s vGIC-ITS emulation, so it matters only where KVM is actually used to run guests:

ls -l /dev/kvm

Does the platform expose a GICv3/4 ITS? The vulnerable code emulates the ITS; a host GIC with ITS is the usual case on server-class arm64:

ls /sys/firmware/devicetree/base 2>/dev/null | grep -i its

Public PoC

The upstream PoC is in V4bel/ITScape; it is built on the kernel’s in-tree KVM selftest and, on a successful escape, creates /ITScape on the host. Do not run it on a system you are not authorised to test.

Mitigation

The real fix is a patched kernel (the 13031fb6b835 backport). There is no clean runtime mitigation — the bug is reached through ordinary guest ITS operations, so it cannot be disabled without breaking interrupt delivery for guests. Until a patched kernel is installed, the only risk-reducing postures are operational:

• Do not run untrusted arm64 guests on an unpatched host — a guest with EL1 is all the attacker needs.
• Where guests are semi-trusted, restricting who can open /dev/kvm limits which local users can start a hostile guest, but does not help against an already-running untrusted guest.

Neither is a fix; the kernel hole remains until patched.

Risk notes

• Untrusted-guest arm64 hosts: this is a guest-to-host-root primitive from inside a VM, and the first of its kind demonstrated on KVM/arm64 — the headline risk for arm64 multi-tenant hosts.
• In-kernel, not QEMU: the escape runs with host-kernel privilege, so userspace VMM hardening (seccomp, QEMU sandboxing) does not contain it.
• Narrow window: only 6.10-and-later arm64 kernels are affected, so many stable EL and Debian releases are simply out of scope — check the distribution row before assuming exposure.
• Backports available (CVE-2026-46316): the fix has landed in 6.12.93, 6.18.35, 7.0.12, and 7.1; distro kernels that have not yet adopted one of those releases remain vulnerable. Check the distribution row for your kernel.

Verification log

Last verified 2026-07-13.

Upstream

• The fix is 13031fb6b835 (KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry), first released in v7.1. It uses xa_erase()’s atomic return value so each cache entry is put exactly once even under concurrent invalidation.
• The bug was introduced by 8201d1028caa in v6.10 (2024-04-25); older kernels never had the buggy rework and are not affected.
• CVE-2026-46316 assigned by the kernel CNA (confirmed via vulns.git origin/master; record keys on 13031fb6b835). The .dyad gives the per-branch fixed versions used in the Upstream fixed versions table; the CNA scored it CVSS 3.1 8.8 (AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H).
• Stable backports landed: 6.12.93, 6.18.35, and 7.0.12 all carry the fix (per the vulns.git .dyad); every maintained in-window branch is therefore already patched upstream, so only distro adoption lags.

Distributions

• Debian (via the dak madison API and Debian security tracker): unstable 7.1.3-1 and testing 7.0.13-1 carry the fix → fixed. Trixie received 6.12.95-1 via trixie-security (DSA-6355-1; ≥ 6.12.93, carries the backport) → trixie now fixed; status flipped from :warning: to :white_check_mark:. Oldstable 6.1.170-3 and oldoldstable 5.10.223-1 predate the v6.10 trigger → not affected.
• NixOS (via the local nixpkgs clone at both channel revisions): the default linuxPackages (linux_6_18) is 6.18.38 on both nixos-unstable and nixos-26.05 (≥ 6.18.35) → carries the backport → fixed. No change.
• Rocky / RHEL family (via the Red Hat security data API and Rocky BaseOS aarch64 repodata): Red Hat lists RHEL 8 kernel Not affected, but RHEL 9 and 10 affected and fixed — RHSA-2026:36018 (5.14.0-687.22.1.el9_8) and RHSA-2026:34911 (6.12.0-211.30.1.el10_2); RHEL 9’s 5.14 kernel carries the vGIC-ITS code by backport despite predating upstream 6.10, so a version-only “predates 6.10” check is wrong for EL 9. Rocky landed both rebuilds on 2026-07-11: Rocky 9 via RLSA-2026:36018 (5.14.0-687.22.1.el9_8) and Rocky 10 via RLSA-2026:36956 (6.12.0-211.32.1.el10_2, NVR ≥ 211.30.1 → carries the backport).
• Amazon Linux: ALAS CVE page confirmed: AL2023 default kernel (6.1) and AL2 (4.14) Not Affected (< 6.10). The opt-in kernel6.12 stream was fixed via ALAS2023-2026-1894 and kernel6.18 via ALAS2023-2026-1881 (both 2026-06-22). Prose updated accordingly.
• Proxmox VE: x86-only product — not applicable to this arm64 tracker; see the Januscape tracker instead.

References