VulnerabilityPublished 28 Oct 2026

CVE-2026-99120: Linux kernel · KVM: x86/mmu: Cope with the SS bit being set in #NPF exit codes

Affects Linux kernelSource CVE Database V5

Not known to be exploited · fixed in e90ab3669181c6469e3647ef2b30ae408275f496 : update Linux kernel when convenient.

Data as of 28 Oct 2026, 10:58 UTC

Severity

Unrated

Rated by Threat Radar · CVSS not yet scored by NVD

Patch: Available – fixed in e90ab3669181c6469e3647ef2b30ae408275f496, d6e08ec2fff45e0ec69f11010851650d7c6282b9, 0caeefed99b37f03251a00eb1fdb403a1cf2cb68

Exploitation evidence

Disclosed: evidence found.
CVE published 28 Oct 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

Disclosed: The CVE record is public on cve.org. Its publication is t = 0.
Detectable: A public nuclei template can find exposed instances, for defenders and attackers alike.
Weaponised: Public exploit code exists in Metasploit or Exploit-DB, or CISA SSVC or the CVSS exploit maturity reports a public proof of concept.
Exploited in the wild: CISA KEV lists it, CISA SSVC rates exploitation active, or a source reports attacks.
Observed by OffSeq Mirage: OffSeq Mirage honeypot sensors recorded attack traffic for this CVE, or found exposed hosts without attack traffic.

Moments are spaced evenly, not to scale; a dashed line marks a gap of six months or more. Deltas count from t = 0. Sources that give only a date (CISA KEV, Exploit-DB, or a time of exactly 00:00Z) read “same day” rather than hours. Metasploit modules carry the flaw’s disclosure date, not their release date, and nuclei templates carry no date, so both appear above but not on the timeline.

What to do

Upgrade Linux kernel to e90ab3669181c6469e3647ef2b30ae408275f496, d6e08ec2fff45e0ec69f11010851650d7c6282b9 or 0caeefed99b37f03251a00eb1fdb403a1cf2cb68.

Affected software

Product	Affected	Fixed in
LinuxLinux	Affected ≥ 8db428fd5229ba509d515af10d7f33d7d4a54bfe, < e90ab3669181c6469e3647ef2b30ae408275f496	Fixed in e90ab3669181c6469e3647ef2b30ae408275f496
LinuxLinux	Affected ≥ 8db428fd5229ba509d515af10d7f33d7d4a54bfe, < d6e08ec2fff45e0ec69f11010851650d7c6282b9	Fixed in d6e08ec2fff45e0ec69f11010851650d7c6282b9
LinuxLinux	Affected ≥ 8db428fd5229ba509d515af10d7f33d7d4a54bfe, < 0caeefed99b37f03251a00eb1fdb403a1cf2cb68	Fixed in 0caeefed99b37f03251a00eb1fdb403a1cf2cb68
LinuxLinux	Affected =6.18	Fixed in–

Description

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.

References

Community reviews

Loading reviews…