{"dataType":"CVE_RECORD","dataVersion":"5.2","cveMetadata":{"cveId":"CVE-2026-89915","assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","state":"PUBLISHED","assignerShortName":"Linux","dateReserved":"2026-09-11T19:38:34.775Z","datePublished":"2026-09-16T10:32:11.309Z","dateUpdated":"2026-09-16T14:40:07.892Z"},"containers":{"cna":{"providerMetadata":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-09-16T14:40:07.892Z"},"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: Remove VM-wide VNCR mapping counter\n\nThe global VNCR mapping counter is used to decide whether an L1\nprovided VNCR page is mapped in L0 on any CPU at the point of\ndealing with a TLB invalidation. It is incremented when a mapping\nis made in the fixmap, and decremented when unmapped.\n\nAs it turns out, this tracking has several flaws:\n\n- we are trying to invalidate TLBs, and the mapping is only an\n  opportunistic consequence of the TLB. Checking this counter to\n  decide whether a TLB needs to be invalidated may result in missed\n  invalidations.\n\n- an L1 vcpu invalidating its own TLB (a very likely case) will not\n  succeed in invalidating the VNCR pseudo TLB because that page is\n  not mapped in L0 at this stage.\n\nGiven that this tracking fails at delivering the minimum guarantees\nthat are required and is only a performance optimisation, remove it\ncompletely."}],"metrics":[{"cvssV3_1":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H","baseScore":9.3,"baseSeverity":"CRITICAL"},"scenarios":[{"lang":"en","value":"AV:L - An arm64 nested L1 hypervisor reaches the bug by executing trapped EL1/EL2 TLBI during KVM_RUN; kvm_hyp_handle_tlbi_el2 then skips kvm_handle_s1e2_tlbi. This is local KVM ioctl/guest execution, not a network, adjacent-radio, or physical-device path.\nAC:L - After vcpu_put unmaps the VNCR fixmap, vncr_map_count is zero while vt->valid still caches the HPA, so an L1 TLBI takes the hyp fast path and never invalidates the pseudo-TLB. The attacker controls mapping, unmap, and invalidation; this is the usual L1-after-L2 sequence, not an uncontrollable race.\nPR:N - Exploitation requires no host root or init-namespace capabilities beyond running hypervisor code in a tenant KVM guest on an arm64 host with nested virtualization enabled; the attacker operates entirely from within their assigned VM, consistent with other arm64 KVM nested-virt CVE scoring.\nUI:N - No victim user or administrator action is required beyond the attacker operating their own nested-virtualization workload; VNCR population, vcpu_put unmap, guest TLBI, and L2 re-entry are fully attacker-driven.\nS:C - Missed VNCR invalidation leaves a writable host per-CPU fixmap covering a stale HPA after L1 S1 teardown, so host KVM keeps reading and writing that page while emulating EL2 register state, crossing the guest-to-hypervisor security boundary.\nC:H - The stale VNCR pseudo-TLB retains the old HPA and kvm_map_l1_vncr remaps it PAGE_KERNEL; host NV2/sysreg emulation then reads leftover EL2 register state from a recycled IPA or L2-visible page, a translation-cache use-after-invalidate disclosure primitive.\nI:H - Hardware NV2 and kvm_map_l1_vncr keep a writable kernel mapping of the stale HPA, so nested EL2 register writes land in a page L1 already remapped or reused for L2, giving a use-after-invalidate write primitive against nested hypervisor state and host-mediated guest memory.\nA:H - A stale writable VNCR mapping can oops or panic the host via inconsistent nested MMU or sysreg state, and corrupting L1 EL2 control state or reused pages can hang or crash the hypervisor and co-resident nested guests; the attacker can retrigger the missed-invalidation sequence."}]}],"affected":[{"product":"Linux","vendor":"Linux","defaultStatus":"unaffected","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["arch/arm64/include/asm/kvm_host.h","arch/arm64/kvm/hyp/vhe/switch.c","arch/arm64/kvm/nested.c"],"versions":[{"version":"4ffa72ad8f37e73bbb6c0baa88557bcb4fd39929","lessThan":"5453b85c7ebb605febac3df42021f9471663f051","status":"affected","versionType":"git"},{"version":"4ffa72ad8f37e73bbb6c0baa88557bcb4fd39929","lessThan":"87c2bbf189829dce4aaada8f82e3d54ccc037976","status":"affected","versionType":"git"},{"version":"4ffa72ad8f37e73bbb6c0baa88557bcb4fd39929","lessThan":"c55bc773b6e814406658fae7dc5c15f639ed816e","status":"affected","versionType":"git"}]},{"product":"Linux","vendor":"Linux","defaultStatus":"affected","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["arch/arm64/include/asm/kvm_host.h","arch/arm64/kvm/hyp/vhe/switch.c","arch/arm64/kvm/nested.c"],"versions":[{"version":"6.16","status":"affected"},{"version":"0","lessThan":"6.16","status":"unaffected","versionType":"semver"},{"version":"6.18.52","lessThanOrEqual":"6.18.*","status":"unaffected","versionType":"semver"},{"version":"7.2.5","lessThanOrEqual":"7.2.*","status":"unaffected","versionType":"semver"},{"version":"7.3-rc1","lessThanOrEqual":"*","status":"unaffected","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.16","versionEndExcluding":"6.18.52"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.16","versionEndExcluding":"7.2.5"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.16","versionEndExcluding":"7.3-rc1"}]}]}],"references":[{"url":"https://git.kernel.org/stable/c/5453b85c7ebb605febac3df42021f9471663f051"},{"url":"https://git.kernel.org/stable/c/87c2bbf189829dce4aaada8f82e3d54ccc037976"},{"url":"https://git.kernel.org/stable/c/c55bc773b6e814406658fae7dc5c15f639ed816e"}],"title":"KVM: arm64: Remove VM-wide VNCR mapping counter","x_generator":{"engine":"bippy-1.2.0"}}}}