CVE-2026-45877

What it actually does

CVE-2026-45877 is a local denial-of-service flaw in the Linux kernel Intel Integrated Sensor Hub HID/ISHTP driver path. During a warm reset while ISHTP clients are still being enumerated, the driver can dereference a NULL cl->device pointer in ishtp_bus_remove_all_clients when accessing cl->device->reference_count. This triggers a kernel NULL pointer dereference and panic, causing system availability loss. The reported call path involves intel_ishtp and intel_ish_ipc workqueue reset handling: fw_reset_work_fn -> ishtp_reset_handler -> ishtp_bus_remove_all_clients. The vulnerability requires local access and low privileges, has no direct confidentiality or integrity impact, and affects systems using the relevant Linux kernel driver and Intel ISH hardware/firmware reset paths.

Why it matters to the business

Successful exploitation or accidental triggering can abruptly crash affected Linux systems, interrupting workloads, user sessions, embedded/edge devices, kiosks, developer workstations, or servers that rely on the affected kernel and Intel ISH components. The primary risk is unplanned downtime and operational instability rather than data theft. It is not listed in CISA KEV, has no known ransomware association, and has very low EPSS, so broad internet-scale exploitation is unlikely; however, organizations with fleets of affected laptops, endpoints, or hardware that frequently performs warm resets should prioritize kernel updates through normal patch cycles.

How an attack unfolds

An attacker with local low-privileged access targets a Linux system running an affected kernel with the Intel ISH HID/ISHTP driver in use. The attacker attempts to create timing conditions where a warm reset or firmware reset occurs while ISHTP clients are still being enumerated. If the reset handler removes clients before cl->device has been initialized, the vulnerable code accesses cl->device->reference_count without verifying that cl->device is non-NULL. The resulting NULL pointer dereference occurs in kernel context and causes a kernel panic. Exploitation does not provide code execution, privilege escalation, or data access based on the available description, but it can reliably affect availability if the race/reset condition can be triggered on susceptible hardware.

How to fix it

Apply a Linux kernel update that includes the upstream fix adding a defensive NULL check for cl->device in the Intel ISH HID/ISHTP client removal path. Use vendor-provided kernel packages from the relevant Linux distribution or hardware platform vendor, since fixed package versions were not provided in the input. Prioritize systems with Intel ISH hardware, loaded intel_ishtp/intel_ish_ipc modules, or histories of warm reset instability. Where immediate patching is not possible, consider risk-based mitigations such as disabling or blacklisting the affected Intel ISH/ISHTP modules if the functionality is not required, restricting local shell access, limiting untrusted local code execution, and scheduling maintenance reboots after applying kernel updates. Validate compatibility before disabling HID/sensor-related drivers because this may affect sensor, firmware, or platform-management functionality.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version is at or above the vendor-fixed build containing the intel-ish-hid NULL pointer check. Check distribution security advisories and kernel changelogs for references to the intel-ish-hid, intel_ishtp, or ishtp_bus_remove_all_clients fix. On Linux systems, review loaded modules with commands such as lsmod | grep -E 'intel_ishtp|intel_ish_ipc' to determine exposure, and verify the active kernel with uname -a or package-manager inventory. After patching and rebooting, confirm the updated kernel is active, not merely installed. If operationally safe, perform controlled warm reboot or reset validation on representative hardware and monitor dmesg/journal logs for absence of NULL pointer dereference, KASAN, kernel oops, or panic messages involving ishtp_bus_remove_all_clients, ishtp_reset_handler, fw_reset_work_fn, intel_ishtp, or intel_ish_ipc.

Typical attack path

1. Obtain local interactive, shell, or application-level access to an affected Linux system.
2. Confirm the system is running a vulnerable kernel with Intel ISH/ISHTP HID driver support and relevant hardware present.
3. Induce or wait for warm reset or firmware reset activity affecting the Intel ISH path while clients are being enumerated.
4. Trigger the vulnerable reset cleanup path where ishtp_bus_remove_all_clients processes a client whose cl->device pointer is NULL.
5. Cause a kernel NULL pointer dereference in the intel_ishtp driver, resulting in kernel panic or system crash.
6. Repeat the trigger condition to create recurring denial of service until the kernel is patched or the affected driver path is disabled.

How to detect it

To determine whether this vulnerability was already triggered, review system logs, crash dumps, kernel ring buffers, and centralized Linux logging for kernel oops or panic events involving the Intel ISH/ISHTP driver path. Relevant sources include journalctl -k output, /var/log/kern.log, /var/log/messages, /var/log/syslog, dmesg archives, kdump/vmcore records, KASAN reports, ABRT/apport crash records, and endpoint telemetry that captures kernel panic events. Search for NULL pointer dereference messages and call traces containing ishtp_bus_remove_all_clients, ishtp_reset_handler, fw_reset_work_fn, intel_ishtp, intel_ish_ipc, or ish_fw_update_wq. Correlate events with warm resets, firmware reset activity, reboots, local user sessions, stress testing, or repeated crashes. Because this flaw causes denial of service rather than persistence or code execution, there may be no post-exploitation artifact beyond kernel crash evidence and reboot history.

• KASAN: null-ptr-deref in range [0000000000000000-0000000000000007]
• NULL pointer dereference
• kernel NULL pointer dereference
• ishtp_bus_remove_all_clients
• ishtp_reset_handler
• fw_reset_work_fn
• ish_fw_update_wq
• intel_ishtp
• intel_ish_ipc
• Workqueue: ish_fw_update_wq fw_reset_work_fn
• Call Trace: ishtp_bus_remove_all_clients
• Call Trace: ishtp_reset_handler
• Call Trace: fw_reset_work_fn
• Kernel panic
• Oops: 0000
• BUG: kernel NULL pointer dereference

What your security team should do

• Inventory Linux endpoints and servers for affected kernel versions and presence of Intel ISH/ISHTP modules or hardware.
• Patch affected systems through vendor-supported kernel updates and reboot to activate the fixed kernel.
• Prioritize fleets with repeated warm reboot testing, unstable Intel ISH firmware reset events, exposed local multi-user access, or business-critical availability requirements.
• If patching is delayed, evaluate temporary blacklisting of intel_ishtp or intel_ish_ipc modules where sensor/HID functionality is not required and operational testing confirms no adverse impact.
• Restrict local access and untrusted code execution on affected systems until remediation is complete.
• Add monitoring for kernel panic, oops, KASAN, and NULL pointer dereference messages referencing the Intel ISH/ISHTP call path.
• Review crash dumps and historical kernel logs for prior unexplained crashes matching the vulnerable call trace.
• Track vendor advisories for exact fixed kernel package versions, since fixed versions were not supplied.