CVE-2026-46147

Technical summary

CVE-2026-46147 addresses two synchronization and resource management bugs in __pkvm_init_vcpu() within the ARM64 KVM subsystem. The first issue is a pin reference leak: when hyp_pin_shared_mem() succeeds but a subsequent validation check fails, the error path bypasses unpin_host_vcpu() and unpin_host_sve_state(), leaving host vCPU and SVE state pages pinned indefinitely. The second is a publication ordering violation: the vCPU pointer is stored into hyp_vm->vcpus[] with a bare store instead of smp_store_release(), permitting concurrent pkvm_load_hyp_vcpu() callers to observe a partially constructed vCPU object. The fix introduces a register_hyp_vcpu() helper that performs pre-publication checks, conditionally invokes unpin cleanup on error, and uses smp_store_release()/smp_load_acquire() pairs to enforce memory ordering guarantees.

Business impact

On ARM64 systems running KVM with protected virtual machines, repeated vCPU initialization failures gradually consume kernel memory due to pin leaks, degrading system stability and predictability. Production hypervisor environments may experience resource exhaustion and denial-of-service conditions. The publication ordering issue could permit guest-initiated races that observe vCPU metadata inconsistencies, potentially enabling information disclosure or further exploitation by a privileged guest. The combined effect is reduced availability and weakened isolation guarantees in virtualized infrastructure.

Affected systems

The vulnerability affects the Linux kernel KVM implementation on ARM64 architectures, specifically protected KVM (pkvm) deployments. Systems using standard Linux distributions on ARM64 hardware with kernel-based virtualization enabled are in scope. This includes server platforms and specialized ARM64 virtualization environments. The issue does not affect x86-based KVM or non-virtualized ARM64 systems. Affected kernel versions contain the vulnerable __pkvm_init_vcpu() code path; verify the exact affected range against the Linux kernel security advisories and your distribution's advisory.

Exploitability

Exploitation requires privilege to invoke vCPU initialization, typically restricted to root or the QEMU/hypervisor process. An unprivileged guest cannot directly trigger the bug. However, the resource leak is triggered passively by initialization failures and accumulates over normal operational cycles, making it exploitable through repeated hypervisor reconfigurations. The publication ordering bug is more subtle; while vm_table_lock currently serializes accesses, a concurrent guest or hypervisor component positioned to load vCPU metadata could race with initialization. The barrier fix is defensive and improves robustness against future lockless optimizations or lock ordering changes. Overall exploitability is moderate and primarily relevant to malicious or misconfigured hypervisor administrative operations.

Remediation

Apply the kernel patch that refactors __pkvm_init_vcpu() to extract register_hyp_vcpu() with proper error handling and memory ordering. The patch corrects the cleanup path to unconditionally invoke unpin_host_vcpu() and unpin_host_sve_state() before returning error, and replaces bare stores with smp_store_release() and loads with smp_load_acquire(). Verify the patch version against your distribution's advisory or the upstream Linux kernel stable release notes. No workarounds are available short of disabling ARM64 KVM or protecting vCPU initialization against concurrent reconfiguration at the application level.

Patch guidance

Obtain the fix from your Linux distribution's security advisory or from the upstream kernel repository. Typical deployment involves applying the patch to the kernel source, recompiling, and rebooting. For distributions with automated security update mechanisms (apt, yum, etc.), check for kernel updates addressing this CVE. Test patches in a non-production environment first to verify vCPU creation and destruction workloads complete cleanly and do not regress performance. Monitor system logs post-patch for any memory pressure anomalies that may indicate pre-existing leaks. Verify against your vendor advisory for exact version numbers.

Detection guidance

Monitor kernel memory usage trends, particularly slab allocation for kvm and pin-related structures, using /proc/meminfo or kernel memory profiling tools (e.g., 'slabtop'). A gradually rising baseline during repeated vCPU lifecycle operations may indicate the leak. For systems with CONFIG_DEBUG_KMEMLEAK enabled, enable leak detection and scan for unreleased pin references after stress testing vCPU initialization paths. Audit hypervisor logs for vCPU creation failures; each failure event without recovery increases leak risk. Systemtap or eBPF probes on hyp_pin_shared_mem() and unpin_host_vcpu() can quantify leak events in production. There is no direct user-space symptom; detection requires privileged kernel observation.

Why prioritize this

Although the CVSS score is 5.5 (Medium), this vulnerability warrants priority in ARM64 KVM environments due to the combination of resource exhaustion (availability impact) and synchronization hazards (integrity/confidentiality risk via race conditions). Production hypervisor deployments are especially critical because gradual resource leaks degrade cluster stability and may interact badly with orchestration systems. The lack of user-facing exploit primitives and the privilege requirement lower urgency for non-virtualized or x86-only systems, but ARM-based cloud and edge infrastructure should prioritize patching.

Risk score, explained

CVSS 3.1 Medium (5.5) reflects: AV:L (local, hypervisor privilege required), AC:L (leak occurs under normal error conditions), PR:L (privileged administrative context), UI:N (no user interaction), S:U (single security boundary), C:N (no confidentiality loss), I:N (no direct integrity violation), A:H (high availability impact via resource exhaustion). The rating does not fully capture the synchronization hazard and potential for information leakage via races; however, the barrier fix is defensive and mitigates speculative worst-cases. The score appropriately flags this as a medium-priority patch candidate.

Frequently asked questions