Cloudanix VulnDB

CVE-2026-99120

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's handling of virtual machine memory faults can produce warnings or crashes on host servers when certain guest operating systems run.

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

What it actually does

Unexpected SS bit in nested page fault error codes triggers out-of-bounds array access inside permission_fault() when KVM processes shadowed NPT faults on AMD hardware.

Why it matters to the business

Host kernel warnings or UBSAN reports appear when certain guests such as Hyper-V run, potentially causing guest instability or requiring host reboots in virtualized environments.

How an attack unfolds

An attacker-controlled or untrusted guest issues memory accesses that produce page faults carrying the SS bit; KVM passes the unfiltered error code into permission_fault(), which indexes an array with an out-of-range value and logs a warning or triggers UBSAN.

How to fix it

Apply the upstream KVM fix that drops unknown bits from the error code while preserving SS when reflecting faults to L1; rebuild and deploy the updated kernel package on all affected hosts.

How to confirm the fix worked

Boot the fixed kernel, reproduce the Hyper-V or kvm-unit-tests CET workload, and confirm absence of UBSAN array-index-out-of-bounds messages referencing mmu.h:225.

Typical attack path

  1. Attacker starts or compromises a guest VM on an AMD host running affected KVM
  2. Guest triggers page faults with SS bit set in error code (possible with CET or crafted MMU state)
  3. KVM SVM path forwards the error code to permission_fault() without masking unknown bits
  4. Array index exceeds bounds of u16[16] table, producing UBSAN report or WARN

How to detect it

Search kernel logs and dmesg for UBSAN reports citing arch/x86/kvm/mmu.h and index values such as 34, or WARN messages mentioning unknown bits in page fault error codes.

  • UBSAN: array-index-out-of-bounds in arch/x86/kvm/mmu.h:225:27
  • index 34 is out of range for type 'u16 [16]'
  • SS|U|W
  • permission_fault

What your security team should do

  • Patch KVM hosts with the fix within the next maintenance window
  • Add kernel log monitoring for UBSAN and WARN entries containing permission_fault
  • Test nested virtualization workloads with Hyper-V guests before broad rollout

The record

In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Cope with the SS bit being set in #NPF exit codes When running Hyper-V from Windows 11, KVM is seeing the SS bit set in nested page fault error codes produced for shadowed NPT. The AMD manual is unclear about when SS is set, including whether it can be set when SupervisorShadowStackEn (bit 6) is not set in the MISC_CTL field of the VMCB. Nevertheless, the unexpected SS bit causes out of bounds accesses in permission_fault(), seen as either WARNs or UBSAN reports: kernel: UBSAN: array-index-out-of-bounds in arch/x86/kvm/mmu.h:225:27 kernel: index 34 is out of range for type 'u16 [16]' (in this case, the page fault error code is 34*2=0x44, i.e. SS|U; the report shows SS|U|W happening as well). Fix the handling of unknown error codes by dropping SS and (with a WARN) any bits not among those that permission_fault() expects to receive. At the same time, given the uncertainty about when hardware sets SS, follow the processor's behavior when constructing the fault's error code, and preserve the SS bit as passed to FNAME(walk_addr_generic). While the behavior is surprising, there's a possibility that Hyper-V expects it (Hyper-V does not even enable CET unless it finds MBEC/GMET!), so retain the information when reflecting the fault to L1 instead of unconditionally discarding it. Bisection shows that this started happening with commit 687ee95c1b6d ("KVM: nSVM: enable GMET for guests"), even though SHSTK was available to guests since Linux 6.18. However, this is not because bit 1 of MISC_CTL (GMET) somehow enables reporting the SS bit; rather, it's simply that Hyper-V never uses CET unless GMET is also present. The WARN is reproducible even with gmet=0, with some hacking of kvm-unit-tests's cet.c testcase to ensure that the first access to the shadow stack triggers a page fault.

Affected packages

Ecosystem Package Introduced Fixed