{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-89930 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-89930 is a critical vulnerability in Linux, published on 16 Sep 2026. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2026-89930 and fix it if it is affected.\n\nWhat it is: CVE-2026-89930 is a critical vulnerability in Linux, published on 16 Sep 2026. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2026-89930 in the wild and no public exploit code.\n\nAffected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2026-89930/ (Markdown: https://insights.sbomify.com/CVE-2026-89930/index.md)","id":"CVE-2026-89930","markdown":"https://insights.sbomify.com/CVE-2026-89930/index.md","name":"CVE-2026-89930","record":{"aliases":["AZL-101532","BELL-CVE-2026-89930","DEBIAN-CVE-2026-89930","GHSA-j569-2qg3-pw8x","UBUNTU-CVE-2026-89930"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["data_read","privilege_escalation"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel KVM","requires_auth":"none","summary":"A missing TLB flush in KVM nested virtualization could allow an attacker to read stale memory or escalate privileges.","user_interaction":"not_required","vuln_class":"other"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[],"cvss":{"score":9.3,"severity":"critical","source":"cna","vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H","version":"3.1"},"cwes":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: nVMX: Service local TLB flushes on failed nested VM-Enter\n\nKVM services local TLB flushes on \"full\" nested VM-Exits (through\n__nested_vmx_vmexit()), but not if a nested VM-Enter fails (e.g. due to\nfailed VMCS checks in nested_vmx_enter_non_root_mode()).\n\nHowever, it is possible that KVM had queued TLB flushes that need to be\nperformed, even if the nested VM-Enter was not successful. For example,\nif VPID is disabled for L2 (via nested_vmx_transition_tlb_flush(), or if\nvia the MSR load lists, as the SDM says:\n\n  If any MSR is being loaded in such a way that would architecturally\n  require a TLB flush, the TLBs are updated so that, after VM entry, the\n  logical processor will not use any translations that were cached before\n  the transition.\n\nThe SDM is unclear about when the TLB flush should occur, and whether or\nnot a failed VM entry would flush the TLB, so it is safer to always\ndo the TLB flush in this case.\n\nMore concretely, KVM also updates the last VPID L1 used for L2 in\nnested_vmx_transition_tlb_flush() (i.e. last_vpid), even if the VM entry\nultimately fails. With the current code, KVM could miss a TLB flush if\nL1 changes L2's VPID, then does a failed VM entry followed by a\nsuccessful one, as the failed VM entry would update last_vpid but not\nactually flush the TLB. Servicing local TLB flushes on failed VM entries\nmakes sure that the TLB is always flushed when last_vpid is updated.","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"KVM: nVMX: Service local TLB flushes on failed nested VM-Enter","id":"CVE-2026-89930","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"other","year":"2026"},"n_packages":0,"n_references":7,"next":{"headline":"KVM: nVMX: Ensure KVM_REQ_GET_NESTED_STATE_PAGES is cleared on VM-Exit","id":"CVE-2026-89931"},"packages":[],"prev":{"headline":"KVM: nVM: Ensure INVVPID is emulated on the correct physical CPU","id":"CVE-2026-89929"},"products":["Linux"],"published":"2026-09-16","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-10-19","vendors":["Linux"]},"summary":"A missing TLB flush in KVM nested virtualization could allow an attacker to read stale memory or escalate privileges.","url":"https://insights.sbomify.com/CVE-2026-89930/"}