Cloudanix VulnDB

CVE-2026-99186

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A programming mistake lets any regular user freeze a CPU core inside the operating system kernel, forcing a reboot to recover.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Trivial
Impact
Denial Of Service
Component
OS kernel
Class
Denial of service
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Shadowed loop counter variable in for_each_insn_prefix() macro causes get_seg_reg_override_idx() to always return default segment and, with CS prefix, enter infinite loop inside UMIP emulation path of the #GP handler.

Why it matters to the business

Unprivileged local users can trigger kernel-level CPU spinning that prevents task termination and requires a reboot, leading to denial of service on affected Linux systems.

How an attack unfolds

An attacker executes a user-space instruction (SGDT/SIDT/SMSW) that triggers #GP, supplies a CS segment override prefix, and enters the broken UMIP emulation path; the kernel loop never exits, the SIGKILL is never delivered, and the CPU remains occupied until reboot. FS/GS prefixes cause incorrect memory writes instead.

How to fix it

Update to a Linux kernel containing the fix that renames the iterator variable inside the for_each_insn_prefix() macro. Reboot after applying the kernel package update.

How to confirm the fix worked

Verify the running kernel version contains commit 45e1dccc0653 or the subsequent rename of the macro iterator; attempt reproduction of the SGDT instruction with CS prefix and confirm the process terminates normally.

Typical attack path

  1. Compile or obtain unprivileged binary that issues SGDT/SIDT/SMSW with memory operand and CS prefix
  2. Execute the binary on an unpatched kernel
  3. Kernel enters infinite loop in UMIP emulation inside #GP handler
  4. Task becomes unkillable and CPU is consumed until forced reboot

How to detect it

Look in kernel logs for repeated #GP entries from UMIP emulation paths or processes stuck in uninterruptible state after SIGKILL; examine audit logs for execution of SGDT/SIDT/SMSW instructions from user space.

What your security team should do

  • Prioritize kernel updates on all x86 Linux systems within the next maintenance window
  • Restrict unprivileged access to UMIP-emulated instructions via seccomp or LSM policies until patched
  • Monitor for high CPU usage by unprivileged processes that do not terminate after SIGKILL

The record

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 ]

Affected packages

Ecosystem Package Introduced Fixed