CVE-2026-46147

What it actually does

This Linux kernel KVM arm64 issue affects protected KVM vCPU initialization. A local user with permission to create or manipulate KVM virtual machines can trigger error paths after shared memory is pinned, causing host vCPU and SVE state page pin references to leak. Repeated triggering can permanently consume kernel resources and degrade or exhaust memory availability. A second ordering bug can publish a vCPU pointer before the object is fully initialized, allowing a concurrent load path to observe inconsistent state; depending on timing, this may cause kernel instability, crashes, or denial of service. The primary impact is host availability loss, not data disclosure or privilege escalation.

Why it matters to the business

Systems using KVM virtualization on affected ARM64 Linux hosts may experience VM failures, host instability, degraded performance, or outages if a local user or compromised workload can repeatedly exercise the vulnerable vCPU initialization path. Because the issue is local and requires KVM access, exposure is highest on multi-tenant virtualization hosts, developer systems, CI runners, edge platforms, and ARM64 cloud or appliance environments that allow untrusted users to create virtual machines. There is no current KEV listing, no known ransomware use, and EPSS is low, so broad opportunistic exploitation is unlikely, but the operational impact can be severe on affected virtualization infrastructure.

How an attack unfolds

An attacker first obtains local access to an affected ARM64 Linux system with sufficient privileges or group membership to interact with KVM, such as access to /dev/kvm. The attacker then repeatedly creates or initializes KVM vCPUs in a way that causes validation to fail after protected KVM has already pinned host vCPU or SVE state memory. On vulnerable kernels, the failure path does not release the pin references, so each attempt can leak pinned kernel resources. Over time, this can exhaust memory or related kernel accounting resources, causing VM creation failures, service degradation, or host instability. In a race-oriented variant, the attacker attempts to trigger concurrent vCPU initialization and loading so another path observes a partially initialized vCPU object, potentially leading to kernel faults or crashes. No public exploitation maturity is indicated, and successful exploitation is expected to require local KVM access and ARM64 pKVM-relevant kernel configuration.

How to fix it

Upgrade to a Linux kernel version that contains the upstream fix for the KVM arm64 protected vCPU initialization pin-leak and release/acquire ordering bug. No exact fixed package versions were provided in the input, so use your Linux distribution vendor advisory, kernel stable release notes, or appliance vendor bulletin to identify the corrected kernel build. Prioritize ARM64 systems that run KVM, pKVM, nested or protected virtualization features, CI virtualization workloads, or multi-tenant VM hosting. If immediate patching is not possible, reduce exposure by restricting /dev/kvm access to trusted administrators and service accounts only, disabling unneeded KVM usage on ARM64 hosts, preventing untrusted users from creating VMs, and isolating high-risk virtualization workloads. A reboot into the fixed kernel is required for the remediation to take effect.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, has been updated to a build containing the fix. Validate with distribution package metadata, changelogs, or source patches referencing the KVM arm64 __pkvm_init_vcpu(), register_hyp_vcpu(), smp_store_release(), and smp_load_acquire() changes. Check that the system has rebooted into the fixed kernel using uname -a or equivalent host inventory tooling. For exposure validation, identify ARM64 hosts with KVM enabled and accessible /dev/kvm, then review permissions and active virtualization services. After remediation, perform controlled VM/vCPU creation tests on representative ARM64 KVM hosts and monitor dmesg/journal logs for KVM, pKVM, memory allocation, hung task, or kernel oops messages. Absence of crashes or leak-like behavior during normal VM lifecycle testing supports, but does not alone prove, remediation; kernel version verification remains authoritative.

Typical attack path

1. Gain local access to an affected ARM64 Linux system.
2. Obtain permission to use KVM interfaces, commonly through root privileges, virtualization management privileges, or membership in a group with /dev/kvm access.
3. Create or manipulate KVM virtual machines and vCPUs to reach the protected KVM vCPU initialization path.
4. Trigger initialization failure after shared memory pinning has succeeded.
5. Repeat the operation to leak pinned host vCPU and SVE state page references.
6. Optionally attempt concurrent vCPU initialization/load activity to expose the publication-ordering race.
7. Cause resource exhaustion, VM failures, kernel warnings, host instability, or a host denial of service.

How to detect it

To assess possible prior exploitation, focus on ARM64 Linux systems with KVM enabled and users or services able to access /dev/kvm. Review kernel logs from dmesg, journald, syslog, kdump/vmcore analysis, and virtualization service logs for unexplained host instability, kernel oopses, hung tasks, memory allocation failures, or VM creation failures around KVM arm64 or pKVM activity. Correlate these events with audit logs showing access to /dev/kvm, repeated VM/vCPU creation attempts, qemu-system-aarch64 or other VMM process activity, and nonstandard users invoking virtualization tooling. Look for crash stack traces or symbols involving __pkvm_init_vcpu(), pkvm_load_hyp_vcpu(), hyp_pin_shared_mem(), host vCPU pinning, or SVE state handling. Because this bug primarily causes denial of service and resource leakage, there may be no durable file-based artifact after reboot unless kernel logs, crash dumps, or audit telemetry were retained.

• __pkvm_init_vcpu
• pkvm_load_hyp_vcpu
• hyp_pin_shared_mem
• unpin_host_vcpu
• unpin_host_sve_state
• register_hyp_vcpu
• KVM: arm64
• pKVM
• /dev/kvm
• qemu-system-aarch64
• Unable to handle kernel NULL pointer dereference
• Kernel panic - not syncing
• BUG: kernel NULL pointer dereference
• INFO: task hung
• page allocation failure
• Out of memory: Killed process

What your security team should do

• Inventory ARM64 Linux hosts running KVM or protected KVM and prioritize them for kernel updates.
• Patch and reboot affected virtualization hosts using vendor-confirmed fixed kernel packages.
• Restrict /dev/kvm access to trusted users and service accounts until all affected systems are remediated.
• Review virtualization management platforms, CI runners, developer hosts, and edge ARM64 systems for untrusted VM creation capability.
• Monitor kernel logs for KVM arm64, pKVM, hung task, memory pressure, allocation failure, and kernel oops events on affected hosts.
• Investigate repeated failed VM or vCPU creation attempts, especially from non-administrative users or unexpected automation accounts.
• If kernel instability is observed, preserve dmesg, journal, crash dumps, VM lifecycle logs, and process/account activity before rebooting where operationally feasible.
• Track distribution and appliance advisories because exact fixed versions vary by vendor kernel branch.