CVE-2026-43324

Published: Mag 08, 2026 Last Modified: Mag 08, 2026

ExploitDB:

Other exploit source:

Google Dorks:

Description

AI Translation Available

In the Linux kernel, the following vulnerability has been resolved:

USB: dummy-hcd: Fix interrupt synchronization error

This fixes an error in synchronization in the dummy-hcd driver. The
error has a somewhat involved history. The synchronization mechanism
was introduced by commit 7dbd8f4cabd9 ('USB: dummy-hcd: Fix erroneous
synchronization change'), which added an emulated 'interrupts enabled'
flag together with code emulating synchronize_irq() (it waits until
all current handler callbacks have returned).

But the emulated interrupt-disable occurred too late, after the driver
containing the handler callback routines had been told that it was
unbound and no more callbacks would occur. Commit 4a5d797a9f9c ('usb:
gadget: dummy_hcd: fix gpf in gadget_setup') tried to fix this by
moving the synchronize_irq() emulation code from dummy_stop() to
dummy_pullup(), which runs before the unbind callback.

There still were races, though, because the emulated interrupt-disable
still occurred too late. It couldn't be moved to dummy_pullup(),
because that routine can be called for reasons other than an impending
unbind. Therefore commits 7dc0c55e9f30 ('USB: UDC core: Add
udc_async_callbacks gadget op') and 04145a03db9d ('USB: UDC: Implement
udc_async_callbacks in dummy-hcd') added an API allowing the UDC core
to tell dummy-hcd exactly when emulated interrupts and their callbacks
should be disabled.

That brings us to the current state of things, which is still wrong
because the emulated synchronize_irq() occurs before the emulated
interrupt-disable! That's no good, beause it means that more emulated
interrupts can occur after the synchronize_irq() emulation has run,
leading to the possibility that a callback handler may be running when
the gadget driver is unbound.

To fix this, we have to move the synchronize_irq() emulation code yet
again, to the dummy_udc_async_callbacks() routine, which takes care of
enabling and disabling emulated interrupt requests. The
synchronization will now run immediately after emulated interrupts are
disabled, which is where it belongs.

AI Generated Translation

Nel kernel Linux, è stata risolta la seguente vulnerabilità:

USB: dummy-hcd: Correzione errore di sincronizzazione degli interrupt

Questo corregge un problema di sincronizzazione nel driver dummy-hcd. L'errore ha una storia piuttosto articolata. Il meccanismo di sincronizzazione è stato introdotto dal commit 7dbd8f4cabd9 ("USB: dummy-hcd: Fix erroneous synchronization change"), che ha aggiunto un flag "interrupts enabled" emulato insieme a un codice che emula synchronize_irq() (che attende che siano tornate tutte le callback di gestione corrente).

Tuttavia, la disabilitazione degli interrupt emulata avveniva troppo tardi, dopo che il driver contenente le routine di callback di gestione era stato informato che era stato sconnesso e non sarebbero più arrivate callback. Il commit 4a5d797a9f9c ("usb: gadget: dummy_hcd: fix gpf in gadget_setup") ha cercato di risolvere questo spostando il codice di emulazione di synchronize_irq() da dummy_stop() a dummy_pullup(), che viene eseguito prima della callback di sconessione.

Tuttavia, persistono ancora delle race condition, perché la disabilitazione degli interrupt emulata avveniva ancora troppo tardi. Non poteva essere spostata in dummy_pullup(), poiché questa routine può essere chiamata per motivi diversi da una imminente sconessione. Per questo motivo, i commit 7dc0c55e9f30 ("USB: UDC core: Add udc_async_callbacks gadget op") e 04145a03db9d ("USB: UDC: Implement udc_async_callbacks in dummy-hcd") hanno aggiunto un'API che permette al core UDC di indicare esattamente a dummy-hcd quando gli interrupt emulati e le relative callback devono essere disabilitati.

Questo ci porta allo stato attuale, che tuttora presenta un problema: la funzione emulate synchronize_irq() viene eseguita prima della disabilitazione degli interrupt emulati! Questo non va bene, perché significa che possono ancora verificarsi interrupt emulati dopo l'esecuzione di synchronize_irq(), con il rischio che un handler di callback sia in esecuzione quando il gadget driver viene sconnesso.

Per risolvere, dobbiamo spostare ancora una volta il codice di emulazione di synchronize_irq() alla routine dummy_udc_async_callbacks(), che si occupa di abilitare e disabilitare le richieste di interrupt emulati. La sincronizzazione verrà ora eseguita immediatamente dopo che gli interrupt emulati sono stati disabilitati, che è il momento appropriato.