CVE-2025-21928: Intel ISH HID Use-After-Free Fixed Upstream

A subtle memory-management mistake in the Intel ISH HID driver has been assigned CVE-2025-21928 and fixed upstream — the bug is a classic use-after-free in ishtp_hid_remove() that can cause random system crashes shortly after the driver is removed and therefore represents a real availability hazard for affected Linux hosts.

Background / Overview​

Human Interface Device (HID) drivers are deceptively complex: they translate binary device descriptors and event streams into input events the kernel and user space consume. The Intel ISH (Intel Sensor Hub) HID driver implements HID-over-ISHTP (Intel Sensor Hub Transport Protocol) integrations used by on‑board sensors and sensor hubs on many platforms. Problems that appear during driver teardown — particularly ordering mistakes that free resources while other teardown helpers still reference them — frequently produce use‑after‑free (UAF) conditions with kernel‑level consequences.
CVE-2025-21928 was publicly disclosed on April 1, 2025 and has been tracked and described by major vulnerability databases and distribution security teams. The issue was scored as high (CVSS v3.1 base 7.8) by common trackers, reflecting the potential for significant impact even though the attack vector is local.

---

What went wrong: the technical root cause​

At removal time the Intel ISH HID driver calls a sequence of cleanup routines that must coordinate between the HID layer, the ISHTP transport layer, and sensor-hub helpers. In the vulnerable code path, the driver freed its per-device driver_data inside the loop that destroys HID devices, before the HID teardown helper hid_destroy_device() completed. That matters because hid_destroy_device() ultimately calls back into code that uses driver_data — for example, to call hid_ishtp_set_feature() to instruct the device to power off gracefully. If driver_data has already been freed, those subsequent calls operate on invalid memory, producing a use‑after‑free and, in practice, random crashes a few minutes after rmmod or equivalent removal events.
More concretely:

• The removal loop iterated HID device structures and freed associated driver state too early.
• hid_destroy_device() (part of the HID core) calls into helpers that expect the driver state to still be valid (for example to send a power‑off feature).
• Freed memory being referenced later yields memory corruption or immediate kernel oopses/panics depending on timing and allocator reuse.

This is a textbook UAF triggered by teardown ordering — an asynchronous, lifecycle‑management bug rather than a parsing or input‑sanitization problem. The fix applied upstream reorders the operations (and/or caches the handle temporarily) so that driver_data is only freed after the HID device is fully destroyed.

---

The upstream fix (what changed)​

Kernel maintainers corrected the teardown sequence to eliminate the window where freed memory could be used. The practical change is simple and deliberate:

• Store the pointer to driver_data in a temporary variable before calling hid_destroy_device() (or otherwise ensure the device is destroyed while the driver_data remains valid).
• Only free driver_data after hid_destroy_device() returns and the HID layer is no longer able to call back into the ISHTP/HID client code.

This small, surgical adjustment removes the use‑after‑free window while preserving the expected power‑off and teardown semantics for the sensor hub. Several stable kernel trees cherry‑picked the change and distribution vendors packaged those upstream fixes into their kernel updates. The kernel‑tree commit references and stable backports are cited in public trackers.

---

Scope, affected versions and severity​

Multiple vulnerability trackers aggregated the affected kernel ranges and published the public severity metrics. The issue was broadly reported as affecting a range of kernels where the intel-ish-hid and related ISHTP HID code paths were present; several trackers list affected series across long‑term and stable kernel releases. The aggregated CVSS v3.1 base score used by many databases is 7.8 (High), indicating this is not a trivial bug from an operational perspective.
Key practical takeaways about scope and exposure:

• Attack vector: Local (an attacker or unprivileged user must be able to remove the driver or otherwise trigger the teardown flow); however, local can be wider than "physically at the machine" in environments that expose device emulation or allow unprivileged device control operations.
• Impact: Availability (random crashes, kernel oops, persistent instability after driver removal). Because the bug is in kernel space, availability loss can be severe for shared or production systems.
• Exploitability: There is no widely published remote exploit or public PoC tied to this CVE at the time of disclosure, but UAFs in kernel code are considered high‑value primitives; attackers with local access or with avenues to trigger driver unloads can exploit the condition to crash or destabilize hosts.

---

Real‑world attack scenarios and threat modeling​

It helps to split likely attack scenarios into practical buckets:

• Local administrative or privileged users removing/reloading modules during maintenance, testing, or misconfiguration can inadvertently trigger the crash on a machine they control. This is accidental exploitation but still operationally impactful for availability.
• Unprivileged local users: in some environments unprivileged users can trigger device detach/teardown sequences (for example via gadget interfaces, devfs manipulations, or by exploiting service misconfigurations). Where this is possible, the vulnerability broadens from "admin-only" to low-privilege local attack surface.
• Virtualization and emulation: device emulation, USB passthrough, or remote device redirection features can let an attacker in a guest supply inputs or removal events that surface on the host. That increases practical exposure in cloud and virtualized deployments where guests can request device redirection.

When modeling risk, treat this CVE primarily as a Denial‑of‑Service / availability problem — but do not underestimate the operational cost: repeated host crashes, unexpected reboots, and unavailable appliances can have substantial business consequences even if confidentiality and integrity remain theoretically unbreached.

---

Vendor responses, patches and distribution coverage​

Distribution vendors and security trackers integrated the upstream fix into their stable kernels and issued advisories. Ubuntu, Debian, Oracle Linux and other distributions added CVE-2025-21928 to their security trackers and mapped the fixed kernel packages or backports accordingly. Security teams should always follow the vendor advisory for their distribution rather than assuming an upstream kernel version number.
Practical signals to act on:

• Search distribution security advisories for your release and kernel package names that list CVE-2025-21928 as fixed.
• If your vendor offers backports or long‑term support updates, they will usually document the stable commit(s) applied — verify those changelogs after installation.

---

Detection, monitoring and forensic signals​

Detecting attempts or incidents that trigger this bug relies on kernel logging and crash‑dump collection:

• Watch dmesg / journalctl -k for oops traces referencing the ishtp/hid layers or for messages that show unexpected NULL/pointer dereference or KASAN reports around ishtp_hid_remove(), hid_destroy_device(), or hid_ishtp_set_feature().
• Host-level indicators: repeated kernel panics shortly after module unloads or device detach sequences, or OOPS traces with call stacks that include ishtp_hid_remove/hid_destroy_device.
• For forensic analysis: capture and preserve crash kernels (kdump), collect full journal logs surrounding the event, and if possible reproduce in a controlled lab environment to confirm the root cause before trying remediation steps that could erase evidence.

Operators should add SIEM/EDR rules to correlate unexpected kernel crashes with local user sessions and device plug/unplug actions — this can help distinguish benign driver problems from targeted attempts to trigger UAFs.

---

Short‑term mitigations (when immediate patching is not possible)​

If you cannot immediately install vendor kernel updates, several pragmatic steps can reduce exposure:

• Prevent the driver from running:
• If the driver is built as a module and not required, unload it: sudo modprobe -r intel_ishtp_hid (module name may vary; confirm via lsmod/modinfo).
• Blacklist the module across reboots using the distribution’s modprobe blacklist mechanism. Note: this removes functionality provided by the driver.
• Restrict device control:
• Limit who can plug or remove devices (USB, PCI‑e hotplug, etc.) and enforce endpoint device control policies to reduce local attack surface. For virtualized workloads, harden USB and device passthrough policies so guests cannot inject or detach host devices.
• Livepatch caution:
• Some livepatch services do not cover every kind of kernel fix — verify whether your vendor’s livepatch offerings cover this particular remediation before relying on them as a stopgap. If livepatch does cover it, test carefully in staging.
• Operational hygiene:
• Schedule a rapid but controlled kernel patch window for high‑risk endpoints (kiosks, shared workstations, appliances), and coordinate reboots to bring hosts into patched kernels reliably.

These are mitigations of last resort — the only reliable long‑term remediation is applying vendor‑supplied patched kernels and rebooting into them.

---

How to verify a successful remediation​

After deploying vendor kernel updates or backports:

• Reboot into the updated kernel and confirm the running kernel version (uname -r).
• Confirm the kernel package changelog or vendor advisory mentions the upstream commit or CVE‑fix. Distributions typically list the stable commit(s) applied in the changelog or advisory.
• If the driver is modular and you previously blacklisted or unloaded it for mitigation, verify module behavior: ensure you can load/unload the module without triggering the previous oops.
• Re-scan assets with your vulnerability scanner and confirm that CVE-2025-21928 is no longer flagged on the host.

If you still observe OOPS traces referencing ishtp_hid_remove or hid_destroy_device after patching, collect crash dumps and escalate to your vendor support channel for triage — there may be an environment- or configuration-specific regression to investigate.

---

Why this class of bug keeps appearing in device drivers​

Device drivers juggle asynchronous events — device connect, device disconnect, runtime suspend/resume, deferred work, and user space interactions — and they must do so while carefully managing object lifetimes and reference counts. The UAF in ishtp_hid_remove is an archetypal lifecycle bug: an object was freed while another code path could still access it during teardown. Automated tools like KASAN and Syzkaller, plus conservative code reviews, are effective at finding these issues, but they remain common because the domain mixes concurrency, hardware timing, and multiple subsystem callbacks. The kernel community tends to fix these with minimal, surgical changes (reordering, temporary references, cancellation of deferred work) to avoid regressions.

---

Practical recommendations for administrators and security teams​

• Prioritize patching for machines that:
• Host multiple users or shared services (kiosks, labs).
• Run device-emulation or accept device redirection from untrusted networks or guests (virtualized hosts).
• Are embedded appliances or devices that are not frequently reimaged; these often require vendor coordination to obtain patched firmware/images.
• Short checklist to act now:
• Inventory: identify hosts that load intel-ish-hid / intel_ishtp_hid (lsmod | grep ishtp / modinfo intel_ishtp_hid).
• Consult vendor advisories: map CVE-2025-21928 to the kernel package for your distribution and apply the package.
• Schedule reboots and verify uname -r post‑patch.
• If patching is delayed, unload/blacklist the module where feasible and acceptable.
• Monitor kernel logs for OOPS/KASAN patterns referencing ishtp_hid_remove/hid_destroy_device and collect kdump on crashes.
• Communicate: make sure helpdesk and operations teams know that seemingly random reboots or kernel oops after device operations should trigger an urgent remediation flow — this CVE manifests operationally as instability, not as a noisy network exploit.

---

Critical analysis — strengths of the response and lingering risks​

Strengths

• The upstream fix is small, well‑targeted and conservative: it corrects teardown ordering and avoids broader API changes, which reduces regression risk. Stable kernels accepted the patch and distributions backported it promptly.
• Public tracking by NVD and distributors provides actionable metadata (CVSS, affected series, vendor packages) enabling precise triage and rollout.

Residual risks and caveats

• Local attack vector: while local, the vulnerability becomes meaningful in modern contexts (virtualization, USB redirection, untrusted guests) that expand who can trigger teardown sequences. Operators must consider configuration and hypervisor settings when assessing exposure.
• Embedded and long‑lived devices: appliance fleets and embedded systems that do not receive regular kernel updates may remain exposed indefinitely without vendor cooperation to produce patched images.
• No public PoC ≠ no exploitation: the absence of public exploit code is reassuring but not dispositive; kernel UAFs are valuable primitives for attackers pursuing both DoS and more complex chains. Treat the CVE as a patch‑now item for at‑risk systems.

---

Conclusion​

CVE‑2025‑21928 is a relatively small but important kernel lifecycle bug: an ordering mistake in ishtp_hid_remove() that freed driver state too early and left later teardown helpers referencing invalid memory. The fix is straightforward — preserve the driver_data until after hid_destroy_device() completes — and has been merged into stable kernels and propagated to distribution updates. Administrators should treat this as a high‑priority patch for systems that load the Intel ISH HID driver or that expose device teardown flows to untrusted actors, apply vendor kernel updates, verify the remediation, and use temporary module blacklisting where immediate patching is impractical. Diligent log monitoring and a conservative patch schedule will remove the operational instability this UAF can cause.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center