CVE-2026-89438

What it actually does

The Linux kernel Intel Speed Select Technology (ISST) core-power path did not validate Class of Service (CLOS) IDs or logical CPU IDs before using them to compute MMIO offsets. An out-of-range identifier can cause an out-of-bounds MMIO access in kernel context, which may oops or panic the host, disturb adjacent CPU power-management registers, or enable unintended hardware register access.

Why it matters to the business

This is a local robustness and safety issue on Intel Linux systems that expose ISST/core-power interfaces. The realistic operational outcome is host instability or unexpected CPU power-policy changes that interrupt workloads. It is not in CISA KEV, has no reported ransomware use, exploit maturity is none, and EPSS remains very low and unchanged (~0.002) more than a month after publication, so opportunistic mass exploitation is unlikely. Treat it as a normal kernel-update item rather than an emergency, while still prioritizing Intel hosts that actually load ISST.

How an attack unfolds

A local actor who can invoke the ISST core-power interface supplies a CLOS level or logical CPU number greater than the platform maximum. The kernel uses that untrusted value in an MMIO offset calculation and performs an out-of-bounds hardware access. Impact is typically a kernel fault or corrupted power-management state; whether the interface is reachable without elevated privileges depends on how the host exposes ISST device nodes and modules. No named threat actors, campaigns, or public exploit code are associated with this issue.

How to fix it

Install a Linux kernel that includes the platform/x86 ISST fix which rejects CLOS IDs and logical CPU IDs above the supported maximum before MMIO offset calculation, then reboot onto that kernel. Track your distribution’s kernel security advisory for the mapping of this fix; this record does not list exact package versions. If ISST/core-power is not required, blacklist ISST-related modules and restrict access to ISST device nodes as a compensating control until patched kernels are deployed.

How to confirm the fix worked

Confirm the running kernel changelog or distro CVE mapping includes the ISST CLOS/logical CPU ID validation, and reboot so uname reflects the patched build. Inventory whether ISST modules are loaded and whether ISST device nodes exist. After patching, legitimate ISST core-power operations should continue to work, and out-of-range identifiers should be rejected without a kernel oops. Hosts that never load ISST are not exposed to this specific path.

Typical attack path

1. Obtain local access on a Linux host whose kernel includes Intel ISST/core-power support
2. Reach the ISST user interface (typically the ISST character device or related core-power controls)
3. Submit a core-power request with a CLOS ID or logical CPU ID above the supported maximum
4. The kernel computes an MMIO offset from the unvalidated identifier and performs an out-of-bounds access
5. The host may oops/panic, reboot, or exhibit unintended CPU power-register behavior

How to detect it

No in-the-wild exploit signatures are published. Hunt kernel logs (dmesg, journalctl -k, crash/panic dumps) for oops or BUG traces involving ISST/core-power handling, unexpected opens of ISST device nodes by non-admin processes, and unplanned reboots around Intel Speed Select tooling. Audit logs for device-node access can support the same hunt. Lack of these artifacts does not prove the issue was never triggered; confirm patch level independently.

• /dev/isst_interface
• isst_if_mmio
• isst_if_mbox_pci
• isst_if_common
• intel_speed_select

What your security team should do

• Patch and reboot Intel Linux kernels when the distro advisory containing the ISST CLOS/CPU ID validation is available; this is not a KEV-driven emergency given low EPSS and no known exploitation.
• Inventory systems with ISST modules loaded or ISST device nodes present and patch those first.
• Restrict ISST device-node and sysfs access to trusted administrative tooling only.
• If Speed Select/core-power is unused, disable or blacklist the ISST modules until kernels are updated.
• Watch kernel logs for ISST-related oops/panic traces as a backstop, not as a substitute for patching.