CVE-2026-89442: platform/x86: ISST: Validate socket ID in clos_assoc ioctl
In the Linux kernel, the following vulnerability has been resolved:
platform/x86: ISST: Validate socket ID in closassoc ioctl
isstifclosassoc() validates the user-supplied socketid with 'socketid > topologymaxpackages()', but isstcommon.sstinst[] is allocated with topologymaxpackages() entries, so the valid index range is [0, topologymaxpackages()). The '>' comparison lets socketid == topologymaxpackages() pass and index one entry past the array.
In addition, isstcommon.sstinst[socketid] is NULL for an in-range package that has no bound TPMI SST instance, and the pointer is used without a NULL check. Both the out-of-bounds entry and the NULL pointer are then dereferenced by mappartitionpowerdomainid() and the following powerdomaininfo access.
Reject socketid >= topologymaxpackages() and a NULL sstinst, matching the checks already performed by getinstance().
Affected Software
Event History
Frequently Asked Questions
What systems are exposed to the faulty paths?
The affected paths are reached through the ISST clos_assoc ioctl when it processes a user-supplied socket_id. Exposure includes systems where a caller can submit that ioctl with socket_id equal to topology_max_packages(), or with an in-range socket ID that has no bound TPMI SST instance.
What input conditions can trigger the problem?
A socket_id equal to topology_max_packages() passes the incorrect bounds check and indexes one entry beyond the allocated sst_inst array. An otherwise in-range socket_id can also trigger a NULL-pointer dereference if its corresponding sst_inst entry has no bound TPMI SST instance.
How can I determine whether a kernel contains the vulnerable logic?
Inspect isst_if_clos_assoc() for a bounds check using socket_id > topology_max_packages() and for use of isst_common.sst_inst[socket_id] without rejecting a NULL entry. The corrected logic rejects socket_id values greater than or equal to topology_max_packages() and rejects NULL sst_inst entries.