CVE-2026-99120
UnknownSummary
A Linux kernel vulnerability was fixed in KVM (x86/mmu) where an unexpected SS bit in #NPF exit codes caused out-of-bounds accesses in permission_fault(), resulting in WARNs or UBSAN reports. The issue occurred when running Hyper-V from Windows 11 and was resolved by dropping unknown bits and preserving the SS bit when reflecting the fault to L1.
Risk Assessment
The vulnerability can lead to destabilization of KVM virtual machines, including crashes or incorrect behavior, especially in environments with nested virtualization and Hyper-V. It may also cause false security alerts due to UBSAN reports.
Recommendation
Update the Linux kernel to a version containing the fix. If updating is not possible, consider disabling CET/GMET for KVM guests or avoiding nested Hyper-V configurations until the patch is applied.
Other vulnerabilities in Linux kernel
See all- CVE-2026-58942High
In do_fault_around of memory.c, there is a possible use after free due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed.
- CVE-2026-58847Unknown
In kvm_vfio_pviommu_attach of vfio.c, there is a possible double free due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.
- CVE-2026-58829High
In fuse_backing_mmap of backing.c, there is a possible memory corruption due to a use after free. This could lead to local escalation of privilege with no additional execution privileges needed.
- CVE-2026-58828High
In multiple functions of base.c, there is a possible use-after-free due to a race condition. This could lead to local escalation of privilege with no additional execution privileges needed.
- CVE-2026-58827High
In multiple functions of dma-buf.c, there is a possible use after free due to a race condition. This could lead to local escalation of privilege with no additional execution privileges needed.
- CVE-2026-58826High
In ksys_unshare of fork.c, there is a possible memory corruption due to a use after free. This could lead to local escalation of privilege with no additional execution privileges needed.
- CVE-2026-58825High
In multiple functions of fork.c, there is a possible use after free due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed.
- CVE-2026-99242Unknown
In the Linux kernel, a race between fallocate and mmap reads in NTFS was fixed. Fallocate only took invalidate_lock for punch hole, collapse range and insert range operations, and during standard allocation new clusters were mapped before being zeroed, allowing concurrent mmap page faults to read uninitialized disk data.
- CVE-2026-99241Unknown
In the Linux kernel, a missing lock in ntfs_filemap_page_mkwrite() was fixed; it called iomap_page_mkwrite() without holding mapping->invalidate_lock. A concurrent truncate or fallocate could be invalidating pagecache and rewriting the runlist while the write fault mapped blocks and dirtied the folio.
- CVE-2026-99240Unknown
In the Linux kernel, the DAMON subsystem (mm/damon/core) has a division-by-zero bug when a DAMOS quota goal has a target_value of zero. The fix moves handling of this corner case to the core layer by adding validation in damos_commit_quota_goal(), which now returns an error for zero target values.
Original NVD description (English source)
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS