Cloudanix VulnDB

CVE-2026-98767

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux USB gadget driver can let a bad hardware value crash the entire system with a flood of interrupts.

Exploitation
Local Privilege
Attacker needs
High Privilege
Complexity
High
Impact
Denial Of Service
Component
OS kernel
Class
Improper Input Validation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Writing a value exceeding the event buffer length to the GEVNTCOUNT register in dwc3_check_event_buf() returns IRQ_NONE without clearing the source; the level-triggered DWC3 interrupt remains asserted, producing an unbounded IRQ storm that hits the spurious IRQ handler and triggers a kernel panic.

Why it matters to the business

Affected Linux systems experience immediate kernel crashes and reboots when the USB gadget controller receives malformed event counts, causing unplanned downtime for any device or server relying on the dwc3 driver.

How an attack unfolds

An attacker with the ability to perform arbitrary MMIO writes (local root or compromised firmware) issues a single write of a value larger than the event buffer to the GEVNTCOUNT register at offset 0xc40c; the driver fails to clear the interrupt source, the hardware keeps asserting the line, and the kernel panics within seconds.

How to fix it

Apply the upstream fix that ensures GEVNTCOUNT is always written back even on invalid counts and schedule controller reinitialization; monitor kernel changelogs for the patch that supersedes commit 63ccd26cd1f6.

How to confirm the fix worked

After patching, attempt the devmem write to GEVNTCOUNT and confirm the driver clears the register without entering the spurious IRQ path or triggering BUG at kernel/irq/spurious.c:184.

Typical attack path

  1. Obtain local root or equivalent hardware access on the target
  2. Locate the DWC3 controller base address
  3. Write a value > event buffer length directly to GEVNTCOUNT (offset 0xc40c)
  4. Observe immediate IRQ storm and kernel panic via spurious.c BUG

How to detect it

Search kernel logs for the exact call stack containing __report_bad_irq, note_interrupt, and kernel BUG at kernel/irq/spurious.c:184; correlate with recent writes to DWC3 MMIO regions if audit logging is enabled.

What your security team should do

  • Prioritize patching any kernel images that include the dwc3 gadget driver within the next maintenance window
  • Add kernel panic and spurious IRQ counters to monitoring dashboards for early detection
  • Restrict unprivileged access to /dev/mem or equivalent MMIO interfaces on embedded systems

The record

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.

Affected packages

Ecosystem Package Introduced Fixed