Cloudanix VulnDB

CVE-2026-98765

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in how USB gadget emulation code handles ongoing operations could let parts of the driver shut down while still busy, risking crashes in specialized setups.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Data Tampering
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition in dummy-hcd where request completion handlers can execute after synchronize_irq emulation returns, allowing gadget driver unbind and potential module unload while handlers are active.

Why it matters to the business

Low operational risk due to narrow applicability in USB gadget emulation environments; may cause instability or crashes during driver unload in development or testing setups, with minimal external exposure given low exploit likelihood and no known campaigns.

How an attack unfolds

An attacker with local access triggers USB gadget request completions via timer interrupts while simultaneously forcing driver unbind, exploiting the missing counter increment to race module unload against an active completion handler.

How to fix it

Update the Linux kernel to a version containing the fix that increments callback_usage across request completion callbacks; rebuild and deploy the updated kernel image.

How to confirm the fix worked

Inspect kernel source for the callback_usage increment in completion paths or verify the running kernel version includes the resolved commit; test dummy-hcd unbind under load to confirm no premature module unload.

Typical attack path

  1. Gain local access to a system using dummy-hcd for USB gadget emulation
  2. Initiate gadget driver operations that schedule request completions
  3. Trigger unbind sequence to invoke synchronize_irq emulation
  4. Race completion handler execution against module unload

How to detect it

Review kernel logs for USB gadget unbind sequences coinciding with module unload warnings or oops; examine dmesg for dummy-hcd callback or completion handler activity during driver teardown.

What your security team should do

  • Prioritize kernel update in environments using dummy-hcd for emulation or testing
  • Monitor for any USB gadget related stability issues in affected kernels
  • Review downstream kernel builds and distributions for inclusion of the fix within standard update cycles

The record

In the Linux kernel, the following vulnerability has been resolved: USB: gadget: dummy-hcd: Fix wait for outstanding request completions The dummy-hcd driver emulates synchronize_irq() by waiting until its private callback_usage counter drops to 0 (with the private lock not held). This counter is incremented whenever a gadget driver callback occurs (which requires the private lock to be dropped), but not when a request completion handler is called. This is an oversight. Request completion is triggered by timer interrupts (emulating device IRQs in a real UDC), and the interrupt handlers are supposed to have completed when the synchronize_irq() emulation routine returns -- they aren't supposed to be in the middle of a completion callback. If this happens it can lead to a gadget driver's unbind routine running before all outstanding request completions have finished, maybe even allowing the gadget driver's module to be unloaded while a completion handler is still running. Fix the oversight by incrementing the callback_usage value across request completion callbacks.

Affected packages

Ecosystem Package Introduced Fixed