CVE-2026-89442

What it actually does

An off-by-one bounds check in the Linux kernel Intel Speed Select Technology (ISST) clos_assoc ioctl lets a local caller pass socket_id equal to topology_max_packages() and index one past the sst_inst array. Unbound in-range packages also leave sst_inst NULL with no check. The kernel then dereferences that out-of-bounds or NULL pointer in map_partition_power_domain_id() and subsequent power_domain_info access, producing kernel memory corruption that can crash the host, disclose kernel memory, or enable local privilege escalation.

Why it matters to the business

A low-privileged local user on an affected Intel x86 Linux system with ISST support can take down the host or potentially gain kernel-level control, affecting availability, integrity, and confidentiality of all workloads on that machine. Impact is highest on shared, multi-tenant, CI, or developer Intel servers where untrusted local accounts exist. Remote mass exploitation is unlikely: attack vector is local, exploit maturity is none, EPSS is very low and flat (~0.17% over 30 days), and the issue is not in CISA KEV. Still treat as a High-severity (CVSS 7.8) kernel memory-corruption bug and fold the fix into the next kernel update cycle without delay on hosts that load ISST.

How an attack unfolds

An attacker who already has a local unprivileged account on an Intel x86 Linux host with the ISST platform driver loaded opens the ISST ioctl interface and issues the clos_assoc request. They set socket_id to topology_max_packages() so the defective greater-than check accepts an index one past sst_inst, or they choose an in-range package with no bound TPMI SST instance so sst_inst is NULL. The kernel follows that bad pointer in map_partition_power_domain_id() and related power-domain structures. The result is a kernel oops/panic, a read of adjacent kernel memory, or corruption of kernel objects that can be leveraged for local privilege escalation. No public exploit, ransomware use, or named threat-actor activity is associated with this issue.

How to fix it

Install a Linux kernel that includes the platform/x86 ISST fix for clos_assoc: reject socket_id >= topology_max_packages() and a NULL sst_inst, matching the checks already in get_instance(). Reboot onto the patched kernel. No distro package versions were supplied with this record, so follow your distribution or OEM kernel advisory for the exact build. If a patched kernel is not yet available and Intel Speed Select is not required, unload or blacklist the ISST-related platform/x86 modules and restrict unprivileged access to ISST device nodes until the update can be applied.

How to confirm the fix worked

Confirm the running kernel changelog, distro advisory, or upstream commit contains the ISST clos_assoc socket_id >= topology_max_packages() and NULL sst_inst checks. Compare uname -r / package-manager kernel version to the patched release, then reboot and re-verify. Inventory whether ISST modules are loaded and whether ISST device nodes exist to gauge exposure on unpatched hosts. Do not send crafted clos_assoc ioctls against production systems to prove the bug.

Typical attack path

1. Gain a local unprivileged account on an Intel x86 Linux host that has the ISST platform driver loaded
2. Open the ISST character-device ioctl interface
3. Submit a clos_assoc ioctl with socket_id equal to topology_max_packages() or targeting an unbound SST instance
4. Trigger out-of-bounds or NULL dereference in map_partition_power_domain_id and power_domain_info
5. Cause a kernel panic, leak kernel memory, or corrupt kernel objects to escalate to root

How to detect it

This is local kernel memory corruption with no known in-the-wild exploit, so successful use is most visible as a kernel oops or panic rather than a unique malware implant. Search dmesg, journalctl -k, crash dumps, and kdump/vmcore-dmesg for faults whose call trace includes isst_if_clos_assoc, map_partition_power_domain_id, or other ISST/sst_inst frames, including NULL-pointer and out-of-bounds page-fault oopses shortly after clos_assoc-style ioctls. Audit or eBPF logs showing unprivileged processes opening ISST device nodes (commonly /dev/isst_interface) and issuing ioctls immediately before an oops are suspicious. Correlate with local login, sudo, and container-escape timelines. Absence of these artifacts does not prove the host was never targeted; it only means no noisy crash was recorded.

• isst_if_clos_assoc
• map_partition_power_domain_id
• /dev/isst_interface
• isst_common
• Unable to handle kernel NULL pointer dereference
• Call Trace:
• intel_speed_select

What your security team should do

• Patch and reboot Intel x86 Linux hosts to a kernel that includes the ISST clos_assoc socket ID and NULL sst_inst validation, prioritizing multi-tenant and shared systems
• Identify hosts that load ISST/platform x86 SST modules or expose ISST device nodes and treat those as in-scope until patched
• If Speed Select is unused, unload or blacklist the ISST modules and lock down the device node as a temporary compensating control
• Hunt kernel logs for ISST-related oops/panic stacks; there is no KEV listing, no known exploit, and negligible EPSS movement, so do not treat this as an active incident unless those artifacts appear
• Track vendor kernel advisories for exact package versions, which were not published with this record