CVE-2026-99099 in Linux
Summary
by MITRE • 10/26/2026
In the Linux kernel, the following vulnerability has been resolved:
x86/CPU/AMD: Fix AMD TLBI Erratum #1718
The processor may fail to invalidate a TLB entry while executing an INVLPGB/TLBSYNC instruction pair.
Detect the erratum and apply a software workaround when a microcode fix is not present.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/26/2026
This vulnerability addresses AMD TLBI Erratum #1718, a hardware-level defect affecting certain AMD processor architectures where the Translation Lookaside Buffer (TLB) invalidation mechanism fails to operate correctly under specific conditions. The core technical flaw occurs when the Central Processing Unit executes an INVLPGB instruction followed by a TLBSYNC instruction in sequence. Ideally, this pair of instructions is designed to ensure that all pending address translation cache entries are invalidated and synchronized across processor cores before proceeding with memory operations that rely on updated page tables. However, due to the erratum, there exists a scenario where the CPU may fail to properly invalidate a specific TLB entry despite the execution of these synchronization commands. This failure implies that stale or incorrect virtual-to-physical address mappings can persist in the cache even after software has explicitly requested their removal, creating a window for potential security and stability issues.
The operational impact of this vulnerability is significant because it undermines the fundamental memory isolation guarantees provided by modern operating systems like Linux. When TLB entries are not correctly invalidated, processes may retain access to physical memory pages that they should no longer have permission to read or write. This can lead to information disclosure if a process reads sensitive data from another process's memory space through stale mappings. Furthermore, it poses a risk of privilege escalation if an attacker can manipulate page table structures and exploit the lingering TLB entries to bypass access controls. In severe cases, this inconsistency between logical permissions and actual hardware behavior can cause kernel panics or system instability as the CPU attempts to execute instructions based on corrupted memory state assumptions.
To mitigate this issue without requiring immediate microcode updates from AMD, the Linux kernel implements a software workaround that detects when the processor is affected by Erratum #1718. The detection mechanism typically involves checking specific model and stepping identifiers within the CPU identification leaf data exposed via the cpuid instruction. Once an affected processor is identified, the kernel applies a mitigation strategy that augments or replaces the standard INVLPGB/TLBSYNC sequence with additional instructions designed to force a more thorough cache invalidation. This often involves inserting explicit flush operations or using alternative synchronization primitives that do not rely solely on the potentially flawed hardware implementation of TLBI commands. By applying this workaround, the kernel ensures that memory isolation remains intact even when the underlying silicon does not correctly handle the standard instruction pair.
From a classification perspective, this vulnerability aligns with CWE-200: Exposure of Sensitive Information to an Unauthorized Actor and CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer, as it involves failures in memory access control mechanisms due to hardware defects. In terms of adversarial tactics, this relates to ATT&CK technique T1537: Transfer Data to Cloud Account or potentially techniques involving privilege escalation through kernel exploitation if an attacker can trigger specific race conditions related to TLB state. The resolution emphasizes the importance of microcode updates as the primary fix, with software mitigations serving as a critical fallback for systems that cannot yet receive firmware patches. This layered approach ensures continued system integrity and security across diverse hardware deployments until all affected processors are updated with corrected microcode from AMD.