{"id":"CVE-2026-98715","kind":"vulnerability","aliases":["CVE-2026-98715"],"related":[],"title":"Linux KVM: failed VMRUN on AMD SVM drops a pending TLB flush","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Preserve TLB control (i.e. pending TLB flush) on failed VMRUN\n\nDon't reset the VMCB's TLB control back to \"do nothing\" on a failed VMRUN,\nas empirical testing shows that the CPU performs the requested TLB flush if\nand only if VMRUN is successful, i.e. clearing TLB control on a failed\nVMRUN effectively drops a TLB flush.\n\nExplicitly track the need to flush all ASIDs on a per-CPU basis, as the\nASID reuse condition is tied to the pCPU, not to the vCPU.  As a bonus,\nthis also obviates the need to avoid clobbering FLUSH_ALL_ASID with\nTLB_CONTROL_FLUSH_ASID, e.g. in svm_flush_tlb_asid().\n\nDeliberately don't bother saving/restoring the \"old\" tlb_ctl on failure,\nin quotes because it's not exactly the old tlb_ctl, it's the tlb_ctl from\nafter pre_svm_run(), but before updating tlb_ctl for flush_all_asids.  If\nVMRUN fails and TLB_CONTROL_FLUSH_ALL_ASID is forced, then the next\nsuccessful run of the VMCB *may* unnecessarily flush all ASIDs, which\nstrictly speaking could result in noisy neighbor issues.  However, the\nfact that new_asid() is already guest-triggerable, because of KVM's flawed\nbehavior of clearing the ASID on emulated INIT, means that a guest can\nalready trigger a flush of all ASIDs at roughly the same rate.  And once\nKVM stops clobbering the ASID on emulated INIT, *or* assigns a static ASID\nto each vCPU, this flaw goes away.","summary":"On AMD SVM hosts, KVM cleared the VMCB's TLB control after a failed VMRUN, which dropped a pending TLB flush the CPU would have performed on success. The sources describe a correctness flaw with possible noisy-neighbor effects rather than a confirmed code-execution path.","severity":"unknown","cvss":null,"epss":null,"exploited":false,"exploited_at":null,"products":[],"ecosystems":[],"tags":["amd-svm","hypervisor","kvm","linux","runtime"],"not_affected_if":["intel-only-hosts","no-kvm"],"how_to_check":"- Run `uname -r` on KVM hosts and compare against the fixed kernel in the NVD entry (unknown in the sources)\n- Check whether the host uses AMD CPUs with SVM: `grep -m1 svm /proc/cpuinfo`","fix":"- Update the Linux kernel on KVM hosts to a release containing the upstream fix for CVE-2026-98715 (exact version unknown in the sources)","status":"open","published_at":"2026-10-18T16:17:25+00:00","first_seen_at":"2026-10-23T21:57:16+00:00","triaged_at":"2026-10-25T05:17:28+00:00","updated_at":"2026-10-25T05:17:28+00:00","category":"runtime","confidence":0.5,"triage":{"at":"2026-10-25T05:17:28Z","model":"claude-haiku-5-5","output":{"fix":"- Update the Linux kernel on KVM hosts to a release containing the upstream fix for CVE-2026-98715 (exact version unknown in the sources)","reach":"local","title":"Linux KVM: failed VMRUN on AMD SVM drops a pending TLB flush","impact":"low","summary":"On AMD SVM hosts, KVM cleared the VMCB's TLB control after a failed VMRUN, which dropped a pending TLB flush the CPU would have performed on success. The sources describe a correctness flaw with possible noisy-neighbor effects rather than a confirmed code-execution path.","category":"runtime","nicknames":[],"who_cares":["linux","kvm","amd-svm","hypervisor"],"confidence":0.5,"needs_auth":"unknown","worst_case":"Pending TLB flush dropped; stale translations and possible cross-VM noise","analyst_note":"Find the fixed kernel versions and CVSS score in the NVD entry at https://nvd.nist.gov/vuln/detail/CVE-2026-98715 and the upstream kernel commit.","how_to_check":"- Run `uname -r` on KVM hosts and compare against the fixed kernel in the NVD entry (unknown in the sources)\n- Check whether the host uses AMD CPUs with SVM: `grep -m1 svm /proc/cpuinfo`","needs_analyst":true,"not_affected_if":["intel-only-hosts","no-kvm"],"who_is_affected":"Hosts running Linux KVM virtual machines on AMD processors with SVM enabled are in scope. The sources describe a stale TLB flush after a failed VMRUN, so the risk falls on hypervisor operators, not on guest-only workloads on other hardware; the sources do not say how often a failed VMRUN occurs in practice.","user_interaction":"no","needs_special_setup":"unknown","severity_if_unknown":"unknown"},"cost_usd":0.000715,"input_tokens":3831,"output_tokens":663,"severity_before":"unknown"},"analyst_status":null,"analyst_note":null,"search":"'-2026':14A,17A '-98715':15A,18A 'alreadi':278C,300C 'also':176C 'amd':6A,20B,27B 'amd-svm':19B 'asid':151C,160C,185C,190C,196C,237C,246C,261C,276C,291C,306C,318C,326C 'assign':323C 'avoid':181C 'away':333C 'back':104C 'basi':157C 'behavior':287C 'bonus':174C 'bother':200C 'clear':31B,132C,289C 'clobber':182C,316C 'code':71B 'code-execut':70B 'condit':162C 'confirm':69B 'control':36B,88C,103C,134C,188C,243C 'correct':58B 'could':265C 'cpu':48B,118C,156C 'ctl':205C,218C,223C,233C 'cve':13A,16A 'deliber':197C 'describ':56B 'drop':8A,42B,140C 'e.g':191C 'effect':65B,139C 'empir':113C 'emul':293C,320C 'exact':214C 'execut':72B 'explicit':144C 'fact':273C 'fail':3A,39B,94C,110C,137C,240C 'failur':207C 'flaw':59B,286C,331C 'flush':12A,46B,92C,123C,143C,149C,183C,189C,194C,235C,244C,259C,303C 'follow':79C 'forc':248C 'goe':332C 'guest':280C,298C 'guest-trigger':279C 'host':29B 'howev':271C 'hypervisor':22B 'i.e':89C,131C 'init':294C,321C 'issu':270C 'kernel':77C 'kvm':2A,23B,30B,84C,284C,314C 'linux':1A,24B,76C 'may':257C 'mean':295C 'need':147C,179C 'neighbor':64B,269C 'new':275C 'next':251C 'noisi':63B,268C 'noisy-neighbor':62B 'noth':107C 'obviat':177C 'old':203C,216C 'path':73B 'pcpu':167C 'pend':10A,44B,90C 'per':155C 'per-cpu':154C 'perform':51B,119C 'possibl':61B 'pre':226C 'preserv':86C 'quot':209C 'rate':311C 'rather':66B 'request':121C 'reset':98C 'resolv':83C 'result':266C 'reus':161C 'rough':308C 'run':228C,253C 'runtim':25B 'saving/restoring':201C 'show':115C 'sourc':55B 'speak':264C 'static':325C 'stop':315C 'strict':263C 'success':53B,130C,252C 'svm':7A,21B,28B,85C,193C,227C 'test':114C 'tie':164C 'tlb':11A,35B,45B,87C,91C,102C,122C,133C,142C,187C,195C,204C,217C,222C,232C,242C 'track':145C 'trigger':281C,301C 'unnecessarili':258C 'updat':231C 'vcpu':171C,329C 'vmcb':33B,100C,256C 'vmrun':4A,40B,95C,111C,128C,138C,239C 'vulner':80C 'would':49B","nicknames":[],"mitigations":[],"who_affected":"Hosts running Linux KVM virtual machines on AMD processors with SVM enabled are in scope. The sources describe a stale TLB flush after a failed VMRUN, so the risk falls on hypervisor operators, not on guest-only workloads on other hardware; the sources do not say how often a failed VMRUN occurs in practice.","tier":"C","verified":{},"analyst_revisit_at":null,"first_public_at":"2026-10-18T16:17:25+00:00","kev":null,"cvss_vector":null,"cvss_by":null,"poc_count":0,"sources":[{"source":"nvd","external_id":"CVE-2026-98715","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98715","severity":null,"published_at":"2026-10-18T16:17:25+00:00","modified_at":"2026-10-19T10:19:35+00:00","first_seen_at":"2026-10-23T21:57:16+00:00","fetched_at":"2026-10-23T22:28:56+00:00","note":null}],"documents":[],"notice":"Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai"}