UBUNTU-CVE-2026-99186: Medium severity vulnerability

Published Oct 28, 2026

In the Linux kernel, the following vulnerability has been resolved: x86/insn-eval: Fix shadowed segment index in getsegregoverrideidx() Commit 45e1dccc0653 ("x86/insn: Simplify foreachinsnprefix()") made foreachinsnprefix() declare its own loop counter named idx. getsegregoverrideidx() 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 INATSEGREGDEFAULT, so FS and GS overrides are ignored; - a CS override sets the counter to INATSEGREGCS (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 ]

Event History

Oct 28, 2026
CVE Published
via OSV·12:00 AM
Data Sourced
via OSV·12:00 AM
DescriptionSeverityAffected Software

Frequently Asked Questions

1

Who can trigger the denial of service?

Any local user can trigger it by executing an SGDT, SIDT, or SMSW instruction with a memory operand and a CS prefix, on systems where UMIP emulation reaches the affected #GP handler. The affected task can spin in the kernel and tie up CPUs until reboot.

2

What happens with different segment overrides?

A CS override can cause the kernel prefix-processing loop not to terminate, leaving the task spinning in kernel space. FS or GS overrides are ignored, causing the emulated result to be written to the wrong address.

3

Can a stuck task be terminated normally?

No. The description states that a SIGKILL is not delivered because the task never returns to user space; affected CPUs may remain tied up until the system is rebooted.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203