CVE-2026-46147: Linux Kernel Race Condition Vulnerability

CVE-2026-46147 Overview

CVE-2026-46147 affects the Linux kernel's Kernel-based Virtual Machine (KVM) implementation for arm64, specifically the protected KVM (pKVM) virtual CPU initialization path in __pkvm_init_vcpu(). The vulnerability combines two distinct defects: a pin reference leak on the error cleanup path and a missing memory ordering barrier when publishing a new virtual CPU (vCPU) pointer into the hypervisor virtual machine table. Both issues affect resource lifecycle management and concurrent observability of partially initialized hypervisor objects on arm64 systems running pKVM.

Critical Impact
A failure during vCPU initialization permanently leaks pin references on the host vCPU and SVE state pages, while a concurrent caller of pkvm_load_hyp_vcpu() may observe a partially constructed hyp_vcpu object.

Affected Products

Linux kernel arm64 KVM subsystem (protected KVM / pKVM mode)
Linux kernel branches containing __pkvm_init_vcpu() prior to the upstream fix
arm64 hosts running KVM with Scalable Vector Extension (SVE) state pinning

Discovery Timeline

2026-05-28 - CVE-2026-46147 published to NVD
2026-05-28 - Last updated in NVD database

Technical Details for CVE-2026-46147

Vulnerability Analysis

The defect resides in the arm64 pKVM vCPU initialization logic. When hyp_pin_shared_mem() succeeds and a subsequent check fails, the error path jumps directly to the unlock label without invoking unpin_host_vcpu() or unpin_host_sve_state(). The result is a permanent pin reference leak against the host vCPU and Scalable Vector Extension (SVE) state pages. Repeated failed initializations gradually exhaust pinnable memory and constrain host scheduler decisions.

The second issue concerns memory ordering. The original code publishes the new vCPU pointer into hyp_vm->vcpus[] using a bare store. A concurrent caller of pkvm_load_hyp_vcpu() can therefore observe the pointer before the underlying hyp_vcpu object is fully initialized. While vm_table_lock currently serializes the store and load, the absence of explicit acquire/release semantics leaves the construction unsafe against any future lockless reader path or weakly ordered nested initialization.

Root Cause

The root cause is twofold. First, the cleanup path in __pkvm_init_vcpu() does not symmetrically release resources acquired by hyp_pin_shared_mem(), producing a [Memory Leak] of pin references. Second, the publication of hyp_vm->vcpus[] uses an unordered store, creating a [Race Condition] window in which a reader may dereference a partially constructed object.

Attack Vector

Exploitation requires the ability to trigger vCPU initialization failures on an arm64 host running pKVM. A local privileged user invoking repeated failing initializations can exhaust pinned pages over time. The ordering defect is a latent correctness issue that becomes exploitable if any concurrent reader path observes the vCPU array without holding vm_table_lock. The upstream fix introduces a register_hyp_vcpu() helper that performs the checks and the store, calls unpin_host_vcpu() and unpin_host_sve_state() inline when registration fails, and replaces the bare store with smp_store_release() paired with smp_load_acquire() on the read side. Technical details are available in the Kernel Git Commit Change, the Kernel Git Commit Update, and the Kernel Git Commit Modification.

Detection Methods for CVE-2026-46147

Indicators of Compromise

Growing counts of pinned pages attributed to KVM on arm64 hosts that cannot be reclaimed after VM teardown.
Repeated failures of vCPU creation ioctl calls in kvm logs without matching unpin events.
Unexpected memory pressure on hosts running long-lived pKVM workloads with churning vCPU creation.

Detection Strategies

Audit kernel versions on arm64 KVM hosts and compare against the upstream commits referenced in the CVE.
Instrument hyp_pin_shared_mem() and unpin_host_vcpu() call counts to confirm balanced pin and unpin operations.
Review hypervisor telemetry for partially populated entries in hyp_vm->vcpus[] during concurrent VM startup.

Monitoring Recommendations

Track host memory accounting for pinned shared memory regions over time on arm64 KVM systems.
Alert on kernel warnings or backtraces emitted from __pkvm_init_vcpu() and pkvm_load_hyp_vcpu().
Centralize host kernel logs to correlate vCPU initialization failures with memory pressure events.

How to Mitigate CVE-2026-46147

Immediate Actions Required

Apply the upstream Linux kernel patches referenced in the stable git commits as soon as distribution updates are available.
Inventory arm64 hosts running pKVM and prioritize patching those serving multi-tenant or untrusted guest workloads.
Restrict the ability to invoke KVM vCPU creation to trusted local administrators until the patch is deployed.

Patch Information

The fix introduces a register_hyp_vcpu() helper that consolidates the checks and the store, calls unpin_host_vcpu() and unpin_host_sve_state() inline when registration fails, and replaces the bare publication store with smp_store_release() paired with smp_load_acquire() on the reader. Refer to the Kernel Git Commit Change, Kernel Git Commit Update, and Kernel Git Commit Modification for the authoritative source changes.

Workarounds

Limit the rate and concurrency of vCPU creation operations on affected hosts to reduce the leak window.
Reboot arm64 pKVM hosts on a scheduled cadence to reclaim leaked pinned pages until patches are installed.
Disable protected KVM mode on hosts where it is not required by guest workloads.

bash

# Verify the running kernel version on arm64 hosts
uname -r

# Check for the presence of the fix in the running kernel source tree
git -C /usr/src/linux log --oneline | grep -E '6d69c0ed978f|73b9c1e5da84|7d3c27b54253'