Cloudanix VulnDB

CVE-2026-90329

High · 8.8

CVSS

8.8

EPSS

0.3%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in how the operating system handles certain hardware inputs could let an attacker with physical access crash the system or gain elevated control.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Full Compromise
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Concurrent HID report callbacks can execute during failed probe cleanup, dereferencing freed hidraw objects via their list locks in hidraw_report_event after driver resources are released without synchronization.

Why it matters to the business

Systems handling USB HID devices face elevated risk of local privilege escalation or kernel crashes during driver loading failures, potentially disrupting hardware support and requiring urgent kernel updates across fleets.

How an attack unfolds

An attacker with ability to trigger HID device probe failures (via malformed or adversarial USB devices) forces the race between report callbacks and cleanup, achieving use-after-free to corrupt kernel memory or execute arbitrary code.

How to fix it

Update to a Linux kernel version containing the synchronization fix that stops input before failed-probe cleanup; rebuild and deploy custom kernels if using distribution backports.

How to confirm the fix worked

Confirm the patch is applied by inspecting the HID core probe failure path for the added driver_input_lock reacquisition and wait; test with fault-injection probes on HID devices.

Typical attack path

  1. Attach or emulate a HID device that causes probe to fail after hid_device_io_start
  2. Trigger concurrent report events entering hidraw_report_event while cleanup frees the object
  3. Use the dangling reference through the list lock to corrupt kernel structures
  4. Escalate to full kernel control or cause denial of service

How to detect it

Review kernel logs for HID probe failures followed by use-after-free warnings or oops in hidraw paths; correlate with unexpected hidraw object access patterns post-probe.

What your security team should do

  • Prioritize kernel updates on systems exposing HID interfaces to untrusted devices
  • Monitor for probe failure events in dmesg on high-risk endpoints
  • Restrict physical or virtual USB/HID attachment where feasible until patched

The record

In the Linux kernel, the following vulnerability has been resolved: HID: synchronize input before cleaning up a failed probe hid_device_io_start() allows reports to run concurrently with probe. If the probe subsequently fails, __hid_device_probe() releases driver resources and clears hdev->driver without first excluding those report callbacks. For example, a report may enter hidraw_report_event() while the failure path frees the associated hidraw object, leading to a use-after-free when the report takes the object's list lock. Stop input before performing failed-probe cleanup. This reacquires driver_input_lock and waits for any report callback already in progress.

Affected packages

Ecosystem Package Introduced Fixed