KVM: nVM: Ensure INVVPID is emulated on the correct physical CPU
CVE-2026-89929 · published 16 Sept 2026
How serious is it
- Severity: high, CVSS score 8.8 out of 10.
- No exploit prediction (EPSS) score yet.
- Not on the CISA list of exploited vulnerabilities.
- No public exploit in Exploit-DB.
Is your app affected by CVE-2026-89929?
Paste this prompt into Claude Code, Cursor or any AI coding tool: it runs a free Shippable scan of your project and fixes what it finds. Built with Lovable, Bolt or v0? Scan your live app. Or upload your package file.
Who is affected
- Linux Linux: 5c614b3583e7b6dab0c86356fa36c2bcbb8322a0 to < 1759a565a25c814ced9281a708749c71fa69d6fe, 5c614b3583e7b6dab0c86356fa36c2bcbb8322a0 to < d03e721801ac54b9fdf05668aa0c069f07913b68, 5c614b3583e7b6dab0c86356fa36c2bcbb8322a0 to < 27bdeb5fd19046ffba9ff234e92fe553eb2efb30, 5c614b3583e7b6dab0c86356fa36c2bcbb8322a0 to < 9941850e8adf164d005dbd3774c4b79e91a3cb8e
- Linux Linux: 4.4
How to check
- Find out whether you run the affected product and which version, then compare it with the versions above.
How to fix
Copies a prompt for Claude Code, Cursor or Codex that asks it to check whether you run this product.
- Apply the vendor's update or mitigation from the references below. If there is none yet, limit exposure of the affected service until there is.
- If a vulnerable version was live, check your logs and rotate the secrets that server could read.
The advisory
In the Linux kernel, the following vulnerability has been resolved:
KVM: nVM: Ensure INVVPID is emulated on the correct physical CPU
When emulating INVVPID, KVM executes INVVPID on the physical CPU using
vpid02 (instead of the L1 assigned VPID), after doing some validations
on the operands. However, it is possible that the physical CPU KVM
executes INVVPID on is different from the CPU L2 is running on.
For example, in the following scenario:
- L2 runs on CPU #1 and exits to L1 (vmx->nested.vmcs02.cpu=1)
- L1 migrates to CPU #2 and executes INVVPID
- KVM executes INVVPID on CPU #2
- L1 migrates back to CPU #1 and runs L2 (vmx->nested.vmcs02.cpu=1)
The TLB entries on CPU #1 are never invalidated, because INVVPID was
executed on CPU #2, and vmcs02 never ran on a different pCPU (i.e.
vmx_vcpu_load_vmcs() will *not* request KVM_REQ_TLB_FLUSH).
Ensure that INVVPID is being executed on the same pCPU that L2 last ran
on, and if not, fallback to clearing last_vpid=0 to trigger a full VPID
flush on the next nested VM-Enter (as KVM will detect L1 using a
different VPID for L2). If L2 ends up running on a different pCPU, KVM
will flush the TLB anyway through vmx_vcpu_load_vmcs().
Check your whole app
Dependencies are only half of it. Free and read-only: before you push, run npx shippable-dev scan localhost:3000 in your project folder, no account needed. For your live app, you prove it's yours with a one-line tag first.
References
- git.kernel.org/stable/c/1759a565a25c814ced9281a708749c71fa69d6fe
- git.kernel.org/stable/c/d03e721801ac54b9fdf05668aa0c069f07913b68
- git.kernel.org/stable/c/27bdeb5fd19046ffba9ff234e92fe553eb2efb30
- git.kernel.org/stable/c/9941850e8adf164d005dbd3774c4b79e91a3cb8e
- git.kernel.org/stable/c/6d00e67326d831e6e610933a3800712f4ffe6ec1
Merged from CVE List. Last updated 26 Oct 2026. All vulnerabilities · RSS · JSON