Mitigating ITScape (CVE-2026-46316 and CVE-2026-46317) on Rocky Linux 9 and 10 (arm64)

cve cve-2026-46316 cve-2026-46317 itscape security kernel kvm virtualization arm64 aarch64 rocky linux lts mitigation troubleshooting

Arsalan Zaidi
Customer Support Engineering Lead

Jun 11, 2026

Introduction

This article covers two arm64 KVM vulnerabilities in the Linux kernel, disclosed together and fixed by separate commits:

CVE-2026-46316 (ITScape), a use-after-free in the virtual GIC Interrupt Translation Service (vgic-its) that allows a guest-to-host escape. CVSS 7.0, High.
CVE-2026-46317, a use-after-free in nested MMU handling with a denial-of-service impact. CVSS 7.0, High.

If you run arm64 hosts with KVM guests, update the kernel. That resolves both issues on every affected variant except CIQ Linux Kernel LT 6.12, which has the CVE-2026-46316 fix but not the CVE-2026-46317 fix, and will not receive it through a stable update. See Patched Kernels for the version to install.

Only arm64 (aarch64) hosts running KVM guests are affected. x86_64 is not affected in any configuration. Rocky Linux 8, RLC Pro LTS 9.2, and RLC Pro LTS 9.4 are not affected. If you run no arm64 KVM hosts, this advisory does not apply to you.

A kernel that fixes one of these CVEs does not necessarily fix the other, so check the status of both for your variant.

Problem

CVE-2026-46316 is the more serious of the two. During concurrent interrupt translation cache invalidation, the kernel can drop the cache's reference to a translation entry more than once (a double-put), leaving a freed entry referenced and reachable. A guest with access to an emulated GICv3 ITS can race these operations, corrupt host kernel memory through the resulting use-after-free, and execute code at the host privilege level. The upstream fix is KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry.

CVE-2026-46317 is a distinct use-after-free in nested MMU handling, in arch/arm64/kvm/nested.c rather than the ITS cache. The upstream fix is KVM: arm64: Reassign nested_mmus array behind mmu_lock. Its impact is denial of service rather than privilege escalation.

A further closely related use-after-free is in the process of being assigned a CVE. This article and its update feed will be updated when that identifier is published.

What is affected

Any arm64 host running KVM guests is affected by both CVEs until it runs a patched kernel. This covers RLC Pro LTS 9.6, RLC Pro 9 (el9_8), RLC Pro 10 (el10_2), CIQ Linux Kernel LT 6.12, CIQ Linux Kernel 6.18, and community Rocky Linux 9 and 10 on arm64.

What is not affected

All x86_64 systems, regardless of role, for both CVEs.
arm64 systems that do not run KVM guests, for both CVEs.
Rocky Linux 8, and the CIQ variants built on it, for CVE-2026-46316. The Rocky 8 kernel contains the vgic-its code, which long predates this flaw, but not the April 2024 xarray conversion of the translation cache that introduced the double-put.
RLC Pro LTS 9.2 and 9.4, for CVE-2026-46316, for the same reason. Those kernels predate the xarray conversion: they still use the earlier list-based implementation, with struct vgic_translation_cache_entry entries on an LPI translation cache list, and have no vgic_its_invalidate_cache() function through which to reach the flaw.
arm64 KVM hosts whose guests do not use an emulated GICv3 ITS, for CVE-2026-46316 only. This exclusion does not apply to CVE-2026-46317, which is reached through nested MMU handling and has nothing to do with the ITS. We do not recommend self-assessing against this exclusion: treat all arm64 KVM hosts as in scope and patch them. If you believe it applies to your environment, open a support case and we will confirm.

Each exclusion above applies to the CVE it names, not to both. For CVE-2026-46317 status, use the Patched Kernels table.

Scanner false positives

A vulnerability scanner that matches on kernel version metadata rather than on whether the vulnerable code is present will report CVE-2026-46316 against RLC Pro LTS 9.2 and 9.4. That is a false positive: the accurate status is "not affected," not "affected, awaiting patch." Scanners will also flag x86_64 hosts by kernel NVR alone; those are equally false positives, since neither CVE is reachable on x86_64.

If a scan report conflicts with this article, open a support case and we will confirm the status of your kernel against the source.

Patched Kernels

Status differs per CVE. Check both columns for your variant.

Variant	Patched Kernel Version	CVE-2026-46316 (escape)	CVE-2026-46317 (DoS)
RLC Pro LTS 9.6 (arm64) (CIQLTS-9.6)	`kernel-5.14.0-570.60.1+14.2.el9_6_ciq`, released 2026-06-12	Fixed	Fixed
RLC Pro 9 (arm64) (RLC-9, el9_8)	Current `el9_8` kernel. See the RLC Pro 9 note below.	Fixed	Fixed in current builds
RLC Pro 10 (arm64) (RLC-10, el10_2)	`kernel-6.12.0-211.22.1+2.1.el10_2_ciq`, released 2026-06-22	Fixed	Fixed
CIQ Linux Kernel LT 6.12 (arm64)	`kernel-clk6.12-6.12.95-1.1.el9_clk` or newer	Fixed	No fix available
CIQ Linux Kernel 6.18 (arm64)	`kernel-clk6.18-6.18.38-2.1.el9_clk` or newer	Fixed	Fixed

CIQ updates this table as tested kernels become available.

CIQ Linux Kernel LT 6.12 will not receive the CVE-2026-46317 fix through a routine update. Upstream stable 6.12.y never took the fix and no CIQ backport exists. Installing a newer 6.12 kernel resolves CVE-2026-46316 but will not resolve CVE-2026-46317. Open a support case if that exposure is material for your environment.

RLC Pro 9 note. The CVE-2026-46316 fix is present in every CIQ RLC Pro 9 build on the el9_8 branch, including builds older than any version listed here. The CVE-2026-46317 fix reached the rlc-9 tree later, on 2026-06-10, so only builds from branches rebased after that date carry it. Install the current el9_8 kernel to be certain of both. Hosts still on el9_7 carry neither fix; moving from el9_7 to el9_8 is a stream change rather than a routine update, so plan it as such and contact support if you need the procedure.

Do not compare CIQ kernel versions against Red Hat's. Red Hat fixed CVE-2026-46316 only in 5.14.0-687.22.1.el9_8 and 6.12.0-211.30.1.el10_2, and still lists RHEL 9 and 10 as affected by CVE-2026-46317 with no fix available. CIQ backported both fixes ahead of Red Hat, so a CIQ kernel with a lower NVR than Red Hat's fixed version can still carry the fix. Compare against this table, not against Red Hat advisories.

Relationship to the Arm TLBI advisory. RLC Pro LTS 9.6 also has a separate arm64 advisory, CVE-2025-10263, which lists a later kernel (kernel-5.14.0-570.60.1+15.1.el9_6_ciq, released 2026-06-22) than the build listed above. If both advisories apply to you, install the current LTS 9.6 kernel rather than either specific version.

Resolution

⚠️ These steps reboot the host. On a KVM host, that stops or suspends every running guest, and the guests must be started again afterwards for them to run on the patched host kernel. Confirm a maintenance window before proceeding, and confirm you have console or out-of-band access in case the host does not return.

Where a cluster is available, the safer sequence is to live-migrate guests to an already-patched host first, patch the drained host, and migrate back:

sudo virsh migrate --live <guest> qemu+ssh://<patched-host>/system

Where migration is not available, shut the guests down cleanly and confirm they are down before rebooting:

sudo virsh shutdown <guest>
sudo virsh list --all

Then install the kernel and reboot:

sudo dnf update 'kernel*'
sudo reboot

Quote the glob so the shell does not expand it against the working directory. For the CIQ Linux Kernel variants the package is kernel-clk6.12 or kernel-clk6.18 rather than kernel, and a host not already running CLK needs dnf install rather than dnf update.

If dnf reports nothing to do, the kernel is most likely held back rather than already current. Check for exclusions and version locks before concluding you are patched:

grep -r exclude /etc/dnf/dnf.conf /etc/yum.repos.d/
sudo dnf versionlock list

For RLC Pro LTS variants the patched kernel comes from the long-term support repository with no additional configuration. For RLC Pro 9 and RLC Pro 10, refresh DNF metadata and confirm the correct Depot channel is enabled first; retrieve credentials from the CIQ Portal if needed. For community Rocky Linux 9 and 10 on arm64, see Rocky Linux Errata for availability and update instructions.

Rollback. A kernel update installs alongside the previous kernel rather than replacing it, so the prior kernel remains selectable from the GRUB boot menu if the new one does not boot. Before rebooting, confirm that any out-of-tree or DKMS modules on the host (vendor NIC, GPU, or storage drivers) have been rebuilt for the new kernel, since a module that has not been rebuilt can prevent the host from booting.

Verification

After rebooting, confirm which kernel is running. uname -r prints the version with an architecture suffix and no package name, so rpm -q kernel is easier to compare against the table:

uname -r
rpm -q kernel

If the two disagree, a newer kernel is installed but not booted. Check which kernel the bootloader will select by default:

sudo grubby --default-kernel

Compare the running kernel against the Patched Kernels table for your variant, reading both CVE columns. On RLC Pro 9, a version higher than another does not by itself mean both fixes are present, so install the current el9_8 kernel rather than working from a version comparison.

There is no runtime indicator for either CVE and no mitigation state to verify, since no module-block or sysctl workaround applies. The patched kernel is the resolution. If you need a definitive answer on whether a specific build carries a specific fix, open a support case and we will confirm against the source.

Mitigation

Apply the controls below on hosts you have not yet updated, and on any variant the Patched Kernels table shows as having no fix available.

There is no sysctl or module-blocklist mitigation for either CVE. Two controls do reduce exposure:

If the host does not need to be a hypervisor, removing its KVM role removes the attack surface for both CVEs entirely. Both are reached only from a guest.
Limit affected hosts to trusted guests. Both flaws require a malicious or compromised guest to drive the race from inside a VM. Multi-tenant arm64 virtualization, where untrusted parties control guest workloads, is the highest-risk configuration and should be prioritized for patching.

Identify whether a host is exposed

Run these on the hypervisor, not inside a guest:

uname -m                      # aarch64 = potentially affected
ls -l /dev/kvm                # present = KVM available on this host
sudo virsh list --all         # guests defined and running

A host that reports aarch64, has /dev/kvm, and runs KVM guests is in scope. A host that reports x86_64, or that runs no KVM guests, is not exposed by either CVE.

Notes

Guest kernels do not need patching for these CVEs. Both are host-side flaws in the host's KVM implementation, reached from a guest. Patch the hypervisor.
These are KVM/arm64 virtualization flaws, not general local privilege escalations reachable on every system. The exposure is specific to arm64 hosts running KVM guests.
A public proof-of-concept exists. Treat untrusted multi-tenant arm64 KVM hosts as the priority for patching.
These CVEs are unrelated to the Dirty Frag and Fragnesia page-cache corruption vulnerabilities, which reach the kernel through the IPsec/ESP path. Those mitigations do not apply here, and the controls here do not substitute for the kernel patch.
Do not infer CVE-2026-46317 coverage from a kernel that fixes CVE-2026-46316, and be aware that a scanner keyed to one may report on the other. On the CIQ variants where CVE-2026-46317 is fixed, it arrived through a CIQ backport rather than an upstream rebase.