CVE-2026-98767 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc3: gadget: fix IRQ storm on invalid event buffer count
When dwc3_check_event_buf() reads a GEVNTCOUNT value exceeding the event buffer length, commit 63ccd26cd1f6 ("usb: dwc3: gadget: check that event count does not exceed event buffer length") returns IRQ_NONE without writing back GEVNTCOUNT. Since the DWC3 interrupt is level-triggered, the uncleared IRQ source keeps the line asserted, causing a tight IRQ storm that accumulates 99,900 unhandled interrupts and triggers spurious.c:184 BUG -> kernel panic.
The resulting call stack: __report_bad_irq+0xac/0xc8 note_interrupt+0x340/0x468 handle_irq_event+0xac/0xc0 handle_fasteoi_irq+0x120/0x228 gic_handle_irq+0x68/0x108 ... kernel BUG at kernel/irq/spurious.c:184
To reproduce, write a bogus value exceeding the event buffer length directly to the GEVNTCOUNT register:
devmem <DWC3_BASE + 0xc40c> 4 0x1004
Write the bogus count back to GEVNTCOUNT to clear the IRQ source, consistent with the stale event clearing pattern in dwc3_event_buffers_setup(), and schedule error recovery to reinitialize the controller.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel driver for the DesignWare USB 3.0 (DWC3) gadget interface contains a critical flaw related to interrupt handling when processing invalid event buffer counts. The vulnerability arises from an incomplete implementation of error recovery logic within the dwc3_check_event_buf function, which is responsible for validating that the General Event Count register value does not exceed the allocated event buffer length. When this validation fails and the count exceeds the buffer limit, the driver correctly identifies the condition as unhandled by returning IRQ_NONE to the kernel interrupt subsystem. However, it fails to perform a crucial hardware-level operation: writing back the GEVNTCOUNT register to acknowledge and clear the pending interrupt source. This omission leaves the interrupt line in an asserted state because the DWC3 controller relies on this write-back action to signal that the event has been processed or discarded.
The operational impact of this flaw is severe due to the nature of the hardware interrupts used by the DWC3 controller, which are level-triggered rather than edge-triggered. In a level-triggered interrupt scheme, the CPU continues to receive the interrupt as long as the source line remains asserted. Because the driver returns IRQ_NONE without clearing the GEVNTCOUNT register, the interrupt source is never cleared. This results in an immediate and continuous re-entry into the interrupt handler for the same event, creating a tight loop of unhandled interrupts known as an IRQ storm. The Linux kernel's interrupt subsystem detects this excessive frequency of identical unhandled interrupts and triggers a spurious interrupt detection mechanism. Specifically, after accumulating approximately 99,900 such events, the system hits a BUG condition in kernel/irq/spurious.c at line 184, leading to an immediate kernel panic and a complete denial of service for the host system or device running the affected kernel version.
From a vulnerability classification perspective, this issue aligns with CWE-756: Missing Explanatory Error Message, specifically manifesting as improper error handling that fails to clean up resources or state after detecting an anomaly. It also relates to CWE-401: Memory Leak on Fail Path in the broader sense of resource management failure within interrupt contexts, though more accurately it represents a logic error in hardware register manipulation during exception paths. In terms of ATT&CK mapping, this vulnerability facilitates Denial of Service (T1499) by exhausting system resources and causing a crash through improper handling of external input or internal state inconsistencies. The attack vector is local if an attacker can write to the device memory space via devmem or similar mechanisms, but it primarily affects stability under malformed hardware states or malicious register manipulation during fuzzing scenarios.
To mitigate this vulnerability, developers must ensure that any path returning IRQ_NONE in interrupt handlers for level-triggered devices explicitly clears the corresponding interrupt source at the hardware level before exiting. In the context of the DWC3 gadget driver, this requires writing back the GEVNTCOUNT value to acknowledge the event, even if it is invalid, thereby de-asserting the interrupt line and preventing further re-entry into the handler. Additionally, an error recovery mechanism should be scheduled or executed immediately following this acknowledgment to safely reinitialize the controller state. This ensures that subsequent operations proceed from a known good baseline rather than continuing with corrupted internal structures derived from the malformed event count. System administrators relying on older kernel versions should apply patches that include commit 63ccd26cd1f6 and its follow-up fixes, or upgrade to a version where this logic error has been resolved through proper register write-back procedures in the interrupt handling routine.