Live › vulnerability › CVE-2026-98765
Go to dashboardThe dummy-hcd USB gadget emulator's synchronize routine did not wait for in-flight request completion handlers, so a gadget driver could unbind or unload while a completion callback was still running. The sources do not describe a remote or attacker-controlled trigger; the flaw is a use-after-unbind race in a test/emulation driver.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
No product ranges from the sources yet.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-98765")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.