Skip to main content
VulnerabilityPublished Updated

CVE-2026-43133: Linux kernel · KVM: nSVM: Always use vmcb01 in VMLOAD/VMSAVE emulation

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · CVSS 7.9 High · fixed in fce2fd4a2ca05670a91015aacccf96a1c26268fd : patch Linux kernel soon.

Data as of 26 Oct 2026, 10:24 UTC

CVSS 3.1 base score
7.9High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.1% chance of exploitation in 30 days – higher than 2% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers cannot reliably automate steps 1–4 of the kill chain
Technical impact
Limited control over the software or limited information exposure

CISA SSVC assessment, 2026-10-16.

Patch
Available – fixed in fce2fd4a2ca05670a91015aacccf96a1c26268fd, d464cf1ed900d47c85393d40b00017b6adfc2e6c, c3b7015000988ba35ecd5648f4b2283960f00543 +4
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 6 May 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq 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.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ cc3ed80ae69f454c3d904af9f65394a540099723, < fce2fd4a2ca05670a91015aacccf96a1c26268fd
Fixed in
  • fce2fd4a2ca05670a91015aacccf96a1c26268fd
LinuxLinuxAffected
  • ≥ cc3ed80ae69f454c3d904af9f65394a540099723, < d464cf1ed900d47c85393d40b00017b6adfc2e6c
Fixed in
  • d464cf1ed900d47c85393d40b00017b6adfc2e6c
LinuxLinuxAffected
  • ≥ cc3ed80ae69f454c3d904af9f65394a540099723, < c3b7015000988ba35ecd5648f4b2283960f00543
Fixed in
  • c3b7015000988ba35ecd5648f4b2283960f00543
LinuxLinuxAffected
  • ≥ cc3ed80ae69f454c3d904af9f65394a540099723, < 10063e1251c1485034a018236080792ad083dcc5
Fixed in
  • 10063e1251c1485034a018236080792ad083dcc5
LinuxLinuxAffected
  • ≥ cc3ed80ae69f454c3d904af9f65394a540099723, < 3880e331b0b31d0d5d3702b124f6c93539cd478a
Fixed in
  • 3880e331b0b31d0d5d3702b124f6c93539cd478a
LinuxLinuxAffected
  • ≥ cc3ed80ae69f454c3d904af9f65394a540099723, < 127ccae2c185f62e6ecb4bf24f9cb307e9b9c619
Fixed in
  • 127ccae2c185f62e6ecb4bf24f9cb307e9b9c619

Description

In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Always use vmcb01 in VMLOAD/VMSAVE emulation Commit cc3ed80ae69f ("KVM: nSVM: always use vmcb01 to for vmsave/vmload of guest state") made KVM always use vmcb01 for the fields controlled by VMSAVE/VMLOAD, but it missed updating the VMLOAD/VMSAVE emulation code to always use vmcb01. As a result, if VMSAVE/VMLOAD is executed by an L2 guest and is not intercepted by L1, KVM will mistakenly use vmcb02. Always use vmcb01 instead of the current VMCB.

References

Community reviews

Loading reviews…