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

  KVM: arm64: Handle VNCR TLB invalidation race with vcpu_put() VNCR unmapping

  While VNCR TLB invalidation always occurs under the MMU lock,
  vcpu_put() doesn't, while it…
summary: |-
  In the Linux kernel, the following vulnerability has been resolved:

  KVM: arm64: Handle VNCR TLB invalidation race with vcpu_put() VNCR unmapping

  While VNCR TLB invalidation always occurs under the MMU lock,
  vcpu_put() doesn't, while it…
severity: none
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= 7270cc9157f474dfc46750a34c9d7defc686b2eb <
    5cbd8761d001c11ada73b1753d772c4745a70e72
  - >-
    Linux >= 7270cc9157f474dfc46750a34c9d7defc686b2eb <
    9065c1261f8a05c6a7a2d90048c7c0665ab2896d
  - >-
    Linux >= 7270cc9157f474dfc46750a34c9d7defc686b2eb <
    38640bc32be3fcf9526d477155bc19d3f146231f
  - Linux 6.16
published: '2026-09-16'
updated: '2026-09-16'
sourceUpdated: '2026-09-16T11:17:00.763'
source: NVD
sourceUrl: 'https://nvd.nist.gov/vuln/detail/CVE-2026-89917'
references:
  - url: 'https://git.kernel.org/stable/c/38640bc32be3fcf9526d477155bc19d3f146231f'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/5cbd8761d001c11ada73b1753d772c4745a70e72'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/9065c1261f8a05c6a7a2d90048c7c0665ab2896d'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
tags:
  - nvd
  - cve.org
ingestedAt: '2026-09-16T10:53:53.973Z'
epss: 0.00198
epssPercentile: 0.09869
---

## Overview

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

KVM: arm64: Handle VNCR TLB invalidation race with vcpu_put() VNCR unmapping

While VNCR TLB invalidation always occurs under the MMU lock,
vcpu_put() doesn't, while it unmaps the VNCR page.

The problem is that the invalidation evaluates vncr_tlb::cpu to
decide whether an unmapping needs to take place (cpu != -1) before
performing it. On the other hand, this_cpu_reset_vncr_fixmap()
unconditionally unmaps if L1_VNCR_MAPPED is set.

These two obviously can race, with a TOCTOU pattern on the TLBI
path, and a BUG_ON() on the vcpu_put() path. And the two can end-up
calling vncr_fixmap(-1), with extra lethal effects.

Move the reset of vncr_tlb::cpu to -1 to a common function, and make
this update atomic so that only a single thread can reset the field
and perform the corresponding unmap. The vcpu_put() still need to
unconditionally unmap the current VNCR to close another ugly race.

Finally, the assignment of vncr_tlb::cpu is moved to be kept in sync
with the actual mapping, similar to L1_VNCR_MAPPED being set.

## Remediation

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