Cloudanix VulnDB

CVE-2026-98466

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A memory handling problem in the part of the operating system that runs virtual machines on ARM-based servers could let attackers interfere with protected memory and cause crashes or security breaches.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The fix_host_ownership() function only walked linear-map aliases of memblock regions during stage-2 ownership transfer for KVM on arm64, omitting per-CPU hypervisor stacks that reside in a private VA range protected by guard pages, leaving those pages incorrectly mapped under host stage-2 and enabling memory corruption.

Why it matters to the business

Virtualized workloads on ARM64 systems may experience crashes, data corruption, or isolation failures between the hypervisor and guests, increasing operational risk and potential downtime in cloud or server environments until kernels are updated.

How an attack unfolds

An attacker with the ability to influence KVM memory operations on an affected arm64 host could trigger ownership-transfer paths that skip hypervisor stack pages, resulting in improper stage-2 mappings that allow corruption of sensitive hypervisor memory or escape from guest isolation.

How to fix it

Update to a Linux kernel containing the fix that extends the walker to cover each stack's private VA range; rebuild and deploy the updated kernel on all affected arm64 systems running KVM.

How to confirm the fix worked

Confirm the presence of the updated kernel version; inspect the KVM arm64 code for the modified fix_host_ownership() implementation that iterates over hyp stack VA ranges; test by exercising KVM memory ownership transfer paths in a lab environment.

Typical attack path

  1. Gain access to a guest VM or host process capable of invoking KVM memory-management operations
  2. Trigger conditions that cause fix_host_ownership() to walk memblock regions
  3. Exploit the missing walk of per-CPU hyp stack VA ranges to cause incorrect stage-2 page ownership
  4. Leverage resulting mapping errors to corrupt hypervisor stack or memory structures

How to detect it

Search kernel logs and audit records for unexpected KVM stage-2 faults or hypervisor memory errors around the time of ownership transfer operations; look for crashes or panics referencing hyp stack pages or fix_host_ownership.

What your security team should do

  • Prioritize kernel updates for all arm64 hosts running KVM within the next maintenance window
  • Monitor upstream stable and distribution kernel changelogs for the specific commit
  • Review virtualization workloads for any custom KVM configurations that may increase exposure
  • Plan staged rollouts and regression testing of KVM functionality after patching

The record

In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Transfer the hyp stack pages out of the host stage-2 fix_host_ownership() walks only the linear-map alias of each memblock region, and the per-CPU hyp stack, mapped in the private VA range for its guard page, has none. Walk each stack's VA range with the same walker.

Affected packages

Ecosystem Package Introduced Fixed