CVE-2026-89439

What it actually does

A missing NULL check on isst_common.sst_inst[] in the Linux kernel Intel Speed Select Technology (ISST) platform/x86 driver can allow a NULL pointer dereference after a failed socket load. That typically produces a kernel oops or panic in ISST code paths that assume the per-socket instance array is valid, crashing the host rather than corrupting data or granting privileges.

Why it matters to the business

Impact is availability-only: affected Intel systems that load the ISST driver can hang or reboot, interrupting workloads on that host. Urgency is low. The issue is not listed in CISA KEV, is not associated with ransomware, has no public exploit maturity, and has a very low EPSS (~0.002) that has been flat for 30 days. Exposure is limited to Linux hosts with the ISST driver present (typically Intel platforms using Speed Select), not to typical application-layer services.

How an attack unfolds

An attacker who already has the ability to run code or issue ISST-related operations on a vulnerable kernel would need the driver loaded and a socket-load failure that leaves sst_inst[] NULL. Subsequent use of ISST interfaces that dereference that array without the added check can trigger a kernel NULL dereference and take the machine down. There are no named threat actors, KEV listings, or in-the-wild campaigns associated with this flaw, and it is not a remote unauthenticated RCE path.

How to fix it

Apply your Linux distribution or vendor kernel update that includes the platform/x86 ISST NULL check for isst_common.sst_inst[] after failed socket loading. If a packaged fix is not yet available, track and merge the upstream Linux kernel commit that adds that check, then rebuild and deploy the kernel. Until patched, limit local untrusted access on Intel hosts that load ISST, and avoid exposing ISST management interfaces (sysfs/debug/ioctl-style Speed Select controls) to untrusted users. Reboot into the patched kernel to complete remediation; there is no application-layer configuration workaround that replaces the missing kernel NULL check.

How to confirm the fix worked

Confirm the running kernel changelog or distro advisory lists the ISST sst_inst[] NULL-check fix (platform/x86: ISST). On Intel Speed Select hosts, verify the updated kernel is booted (uname and package version) and that the ISST module or built-in driver matches the patched build. After upgrade, exercise normal ISST/socket bring-up paths in a maintenance window and confirm no kernel oops occurs when socket loading fails. Hosts without the ISST driver or without Intel Speed Select hardware are not in scope.

Typical attack path

1. Obtain local access on a Linux host whose kernel includes the unpatched platform/x86 ISST driver
2. Ensure the ISST driver is loaded on an Intel platform that uses Speed Select
3. Cause or wait for a failed per-socket ISST load so sst_inst[] remains NULL
4. Invoke ISST driver operations that dereference sst_inst[] without a NULL check
5. Trigger a kernel NULL pointer dereference, oops, or panic that denies service on the host

How to detect it

Look for prior exploitation or accidental triggering in kernel logs (journald/syslog/dmesg, crash dumps, kdump/vmcore, and vendor NMI/oops collectors). Search for NULL pointer dereference oopses whose call trace or module path involves ISST / Intel Speed Select (platform/x86 ISST, isst_*, intel_speed_select). Correlate with local logins, privileged process activity, or ISST management tool use around the oops time. There is no network signature; this is a local kernel crash. Absence of such oopses does not prove the host was never vulnerable, only that this path was not hit.

• BUG: kernel NULL pointer dereference
• Unable to handle kernel NULL pointer dereference
• isst_common.sst_inst
• Call Trace: isst_
• platform/x86: ISST
• intel_speed_select
• speed_select_if

What your security team should do

• Treat as a low-priority local denial-of-service kernel robustness fix; do not preempt critical patching unless Intel ISST hosts are high-availability single points of failure
• Inventory Linux kernels on Intel platforms and identify hosts that load the ISST / Speed Select driver
• Deploy vendor or distribution kernel updates containing the ISST sst_inst[] NULL check and reboot into the patched kernel
• Restrict local and management access to ISST-related interfaces until patched
• Monitor kernel logs on remaining unpatched ISST hosts for NULL-dereference oopses in ISST call traces