CVE-2026-99186 in Linux
Summary
by MITRE • 10/28/2026
In the Linux kernel, the following vulnerability has been resolved:
x86/insn-eval: Fix shadowed segment index in get_seg_reg_override_idx()
Commit 45e1dccc0653 ("x86/insn: Simplify for_each_insn_prefix()") made for_each_insn_prefix() declare its own loop counter named idx. get_seg_reg_override_idx() keeps its result in a local of the same name, so the assignments in the loop body now write the loop counter:
- the function always returns INAT_SEG_REG_DEFAULT, so FS and GS overrides are ignored;
- a CS override sets the counter to INAT_SEG_REG_CS (2), the increment makes it 3, and prefixes.bytes[3] holds the last prefix, 0x2e again,
so the loop never terminates.
The UMIP emulation reaches this from the #GP handler for user space: an SGDT, SIDT or SMSW with a memory operand and a CS prefix leaves the task spinning in the kernel, never returning to user space, with a SIGKILL that is never delivered. Any user can thus tie up CPUs until reboot. With an FS or GS prefix, the emulated result is written to the wrong address.
Rename the internal macro iterator variable.
[ Lukas' original patch renamed the use site, I changed it to rename the
iterator in the macro instead, but left Lukas' commit message and authorship - Linus ]
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/28/2026
The vulnerability identified as CVE-2019-15738 represents a critical logic error within the x86 instruction emulation subsystem of the Linux kernel. Specifically, it resides in the function get_seg_reg_override_idx() which is responsible for determining segment register overrides during instruction decoding. The root cause stems from a variable shadowing issue introduced by commit 45e1dccc0653, titled "x86/insn: Simplify for_each_insn_prefix()." This simplification refactored the macro for_each_insn_prefix() to declare its own loop counter named idx internally. However, get_seg_reg_override_idx() also declared a local variable with the identical name idx to store its result. Due to C language scoping rules, assignments intended for the function's local variable inadvertently modified the iterator of the enclosing macro loop instead. This subtle scope collision fundamentally alters control flow and data integrity during instruction emulation operations that involve segment prefix overrides such as FS, GS, or CS prefixes.
The operational impact manifests in two distinct failure modes depending on which segment override is utilized by a user-space application executing privileged instructions like SGDT, SIDT, or SMSW with memory operands under User Mode Instruction Prevention (UMIP) emulation. When an FS or GS prefix is present, the shadowed variable causes the emulated result to be written to an incorrect memory address rather than the intended destination buffer provided by the user-space application. This constitutes a severe data integrity violation where kernel-mode operations corrupt user-space memory locations unpredictably based on loop iteration state. Such behavior can lead to application crashes, potential information leakage if sensitive kernel or adjacent process data is inadvertently exposed through corrupted buffers, and general system instability due to invalid memory writes originating from the privileged execution context of the kernel.
The more severe impact occurs when a CS prefix is applied during these emulation routines. In this scenario, the assignment sets the loop counter idx to INAT_SEG_REG_CS which has a value of two. The subsequent increment operation within the macro advances this index to three. Consequently, the loop accesses prefixes.bytes[3], which contains another instance of the 0x2e prefix byte. Because the condition for terminating the loop relies on reaching a non-prefix byte or exhausting valid indices, and because the iterator is now pointing at an invalid position that still appears as a prefix, the loop enters an infinite execution state. This results in a kernel-level denial of service where the CPU core becomes permanently stuck spinning within this emulation routine. The system fails to return control to user space, preventing any further processing for that thread and effectively tying up the affected processor core until a manual reboot is performed by an administrator.
From a threat actor perspective, this vulnerability allows any unprivileged local user to cause significant disruption to system availability without requiring elevated privileges or exploiting complex race conditions. The attack vector relies on triggering specific instruction sequences with segment overrides in environments where UMIP emulation is active, which is common in modern Linux distributions running under virtualization or protecting against certain side-channel attacks like Foreshadow. By repeatedly invoking these instructions, an attacker can exhaust CPU resources across multiple cores if the vulnerability is triggered concurrently from different processes. This aligns closely with CWE-835: Loop without End and CWE-787: Out-of-bounds Write in terms of logical flow corruption and memory safety violations respectively. In the context of the MITRE ATT&CK framework, this behavior corresponds to T1499: Endpoint Denial of Service, specifically through resource exhaustion via infinite loops or hangs that prevent normal system operation.
The mitigation for this vulnerability involves correcting the variable naming conflict within the instruction emulation codebase. The fix entails renaming either the internal macro iterator variable in for_each_insn_prefix() or the local result variable in get_seg_reg_override_idx() to ensure distinct scopes and prevent accidental overwrites of loop control variables. This patch was integrated into the Linux kernel source tree, addressing the logic error that allowed segment overrides to be ignored or cause infinite loops. Systems running affected versions of the Linux kernel must apply this update through their standard package management systems to restore correct instruction emulation behavior and eliminate the risk of local denial-of-service attacks via CPU resource exhaustion. Administrators should verify that kernel updates are applied promptly, particularly in virtualized environments where UMIP features may be enabled by default for security hardening against speculative execution vulnerabilities.