---
id: CVE-2026-89915
title: |-
  In the Linux kernel, the following vulnerability has been resolved:

  KVM: arm64: Remove VM-wide VNCR mapping counter

  The global VNCR mapping counter is used to decide whether an L1
  provided VNCR page is mapped in L0 on any CPU at the po…
summary: |-
  In the Linux kernel, the following vulnerability has been resolved:

  KVM: arm64: Remove VM-wide VNCR mapping counter

  The global VNCR mapping counter is used to decide whether an L1
  provided VNCR page is mapped in L0 on any CPU at the po…
severity: critical
cvss: 9.3
cvssVector: 'CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H'
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= 4ffa72ad8f37e73bbb6c0baa88557bcb4fd39929 <
    5453b85c7ebb605febac3df42021f9471663f051
  - >-
    Linux >= 4ffa72ad8f37e73bbb6c0baa88557bcb4fd39929 <
    87c2bbf189829dce4aaada8f82e3d54ccc037976
  - >-
    Linux >= 4ffa72ad8f37e73bbb6c0baa88557bcb4fd39929 <
    c55bc773b6e814406658fae7dc5c15f639ed816e
  - Linux 6.16
published: '2026-09-16'
updated: '2026-09-16'
sourceUpdated: '2026-09-16T15:18:17.760'
source: NVD
sourceUrl: 'https://nvd.nist.gov/vuln/detail/CVE-2026-89915'
references:
  - url: 'https://git.kernel.org/stable/c/5453b85c7ebb605febac3df42021f9471663f051'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/87c2bbf189829dce4aaada8f82e3d54ccc037976'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/c55bc773b6e814406658fae7dc5c15f639ed816e'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
tags:
  - nvd
  - cve.org
ingestedAt: '2026-09-16T10:53:53.973Z'
epss: 0.00178
epssPercentile: 0.07611
---

## Overview

In the Linux kernel, the following vulnerability has been resolved:

KVM: arm64: Remove VM-wide VNCR mapping counter

The global VNCR mapping counter is used to decide whether an L1
provided VNCR page is mapped in L0 on any CPU at the point of
dealing with a TLB invalidation. It is incremented when a mapping
is made in the fixmap, and decremented when unmapped.

As it turns out, this tracking has several flaws:

- we are trying to invalidate TLBs, and the mapping is only an
  opportunistic consequence of the TLB. Checking this counter to
  decide whether a TLB needs to be invalidated may result in missed
  invalidations.

- an L1 vcpu invalidating its own TLB (a very likely case) will not
  succeed in invalidating the VNCR pseudo TLB because that page is
  not mapped in L0 at this stage.

Given that this tracking fails at delivering the minimum guarantees
that are required and is only a performance optimisation, remove it
completely.

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.