CVE-2026-89443

What it actually does

A missing bounds check in the Linux kernel Intel Speed Select Technology (ISST) ioctl handlers allows a local user to supply an invalid performance level index that is used as an array offset into the per-level offset table. The result is an out-of-bounds kernel read in isst_if_get_perf_level_mask() and isst_if_get_base_freq_mask(), which can disclose kernel memory (high confidentiality impact) or fault and crash the host (high availability impact). Integrity is not affected. Exploitation requires local access and the ability to issue ioctls against the ISST character device; no remote vector exists.

Why it matters to the business

This is a local kernel memory-safety issue, not a remotely wormable flaw. EPSS is very low (~0.0016 and flat over 30 days), it is not in CISA KEV, and there is no public exploit or ransomware association. Residual risk is to multi-tenant hosts, developer workstations, and any system where untrusted local users or containers can reach the ISST interface: a successful trigger can leak kernel memory useful for further privilege escalation, or cause a kernel oops/panic and unplanned downtime. Urgency is moderate for Intel x86 platforms that expose ISST; systems without the ISST driver or with the device inaccessible to unprivileged users have limited exposure.

How an attack unfolds

An attacker who already has a local, low-privileged account on an affected Intel x86 Linux host opens the ISST userspace interface and issues the performance-mask or base-frequency-mask ioctl with a level value larger than the valid SST-PP range (or a disabled level). Because the mask helpers index perf_levels[] without the bounds checks used by adjacent level-info helpers, the kernel reads past the per-level register/offset table. The attacker observes returned data that may contain out-of-bounds kernel contents, or induces a fault that panics the machine. No named threat actors or in-the-wild campaigns are associated with this issue, and exploit maturity is none.

How to fix it

Apply the upstream Linux kernel fix that adds the same max_level bounds checks used by the adjacent level-info helpers to isst_if_get_perf_level_mask() and isst_if_get_base_freq_mask(), and that rejects disabled SST-PP levels in the perf-mask path. Upgrade to a distribution kernel that includes this ISST validation patch. If a patched kernel is not yet available, restrict access to the ISST userspace device (typically under /dev) so only trusted administrators can open it, unload or blacklist the ISST platform module on hosts that do not need Intel Speed Select, and avoid granting untrusted users or containers CAP_SYS_ADMIN / device access to that interface. No specific vendor package versions were supplied with this record; track your distro's kernel changelog for the ISST 'Validate level in perf mask ioctls' commit.

How to confirm the fix worked

Confirm the running kernel includes the ISST ioctl bounds-check patch (grep kernel changelog or source for validation in isst_if_get_perf_level_mask / isst_if_get_base_freq_mask). On patched kernels, ioctls with level > max_level or disabled SST-PP levels should return an error rather than data. Verify whether the ISST driver is loaded (lsmod / sysfs for isst) and whether unprivileged users can open the ISST device node. After patching, regression-test legitimate ISST tooling (perf-level and base-frequency mask queries with valid levels) to ensure admin workflows still succeed.

Typical attack path

1. Obtain local unprivileged (or container) access on an Intel x86 Linux host with the ISST platform driver loaded
2. Open the ISST ioctl character device exposed to userspace
3. Issue get-perf-level-mask or get-base-freq-mask ioctl with an out-of-range or disabled level index
4. Kernel performs an unchecked read of the per-level offset table
5. Attacker recovers leaked kernel memory from the ioctl result and/or triggers a kernel oops or panic

How to detect it

There are no public exploits, KEV listings, or named actors, so look for local abuse of the ISST ioctl interface rather than a distinctive malware implant. Review kernel logs (dmesg, journalctl -k, crash dumps) for oops/panic stacks in isst_if_get_perf_level_mask, isst_if_get_base_freq_mask, _read_pp_level_info, or _read_bf_level_info. Audit auditd/syscall logs for open/ioctl against the ISST character device from non-admin UIDs, especially around the time of an oops. On hosts with kdump, inspect vmcore for ISST-related page faults. Container runtimes should be checked for devices mounted from the host ISST node. Absence of these artifacts does not prove non-exploitation of a pure OOB read that did not fault.

• isst_if_get_perf_level_mask
• isst_if_get_base_freq_mask
• _read_pp_level_info
• _read_bf_level_info
• /dev/isst_interface
• /dev/isst_if
• platform/x86: ISST
• intel_speed_select
• oops in isst
• kernel BUG at drivers/platform/x86/isst

What your security team should do

• Prioritize kernel updates on Intel x86 hosts that load the platform/x86 ISST driver, especially multi-tenant and developer systems
• Inventory hosts for the ISST module and world-accessible ISST device nodes; restrict permissions or unload the module where Speed Select is unused
• Treat this as a local info-leak/DoS issue: pair with existing local-privilege-escalation hardening (seccomp, no unprivileged user namespaces where policy allows, container device cgroup deny)
• Do not treat as KEV/emergency; EPSS is negligible and no in-the-wild exploitation is reported—schedule with normal kernel patching unless ISST is exposed to untrusted local users
• Monitor kernel oops traces involving ISST ioctl paths until fleets are patched