// For flags

CVE-2024-36950

firewire: ohci: mask bus reset interrupts between ISR and bottom half

Severity Score

4.4
*CVSS v3.1

Exploit Likelihood

*EPSS

Affected Versions

*CPE

Public Exploits

0
*Multiple Sources

Exploited in Wild

-
*KEV

Decision

Track
*SSVC
Descriptions

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

firewire: ohci: mask bus reset interrupts between ISR and bottom half

In the FireWire OHCI interrupt handler, if a bus reset interrupt has
occurred, mask bus reset interrupts until bus_reset_work has serviced and
cleared the interrupt.

Normally, we always leave bus reset interrupts masked. We infer the bus
reset from the self-ID interrupt that happens shortly thereafter. A
scenario where we unmask bus reset interrupts was introduced in 2008 in
a007bb857e0b26f5d8b73c2ff90782d9c0972620: If
OHCI_PARAM_DEBUG_BUSRESETS (8) is set in the debug parameter bitmask, we
will unmask bus reset interrupts so we can log them.

irq_handler logs the bus reset interrupt. However, we can't clear the bus
reset event flag in irq_handler, because we won't service the event until
later. irq_handler exits with the event flag still set. If the
corresponding interrupt is still unmasked, the first bus reset will
usually freeze the system due to irq_handler being called again each
time it exits. This freeze can be reproduced by loading firewire_ohci
with "modprobe firewire_ohci debug=-1" (to enable all debugging output).
Apparently there are also some cases where bus_reset_work will get called
soon enough to clear the event, and operation will continue normally.

This freeze was first reported a few months after a007bb85 was committed,
but until now it was never fixed. The debug level could safely be set
to -1 through sysfs after the module was loaded, but this would be
ineffectual in logging bus reset interrupts since they were only
unmasked during initialization.

irq_handler will now leave the event flag set but mask bus reset
interrupts, so irq_handler won't be called again and there will be no
freeze. If OHCI_PARAM_DEBUG_BUSRESETS is enabled, bus_reset_work will
unmask the interrupt after servicing the event, so future interrupts
will be caught as desired.

As a side effect to this change, OHCI_PARAM_DEBUG_BUSRESETS can now be
enabled through sysfs in addition to during initial module loading.
However, when enabled through sysfs, logging of bus reset interrupts will
be effective only starting with the second bus reset, after
bus_reset_work has executed.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firewire: ohci: enmascara las interrupciones de reinicio del bus entre ISR y la mitad inferior. En el controlador de interrupciones FireWire OHCI, si se ha producido una interrupción de reinicio del bus, enmascara las interrupciones de reinicio del bus hasta que bus_reset_work haya sido reparado y borrado la interrupción. Normalmente, siempre dejamos enmascaradas las interrupciones de reinicio del bus. Inferimos el reinicio del bus a partir de la interrupción de la autoidentificación que ocurre poco después. En 2008 se introdujo un escenario en el que desenmascaramos las interrupciones de reinicio del bus en a007bb857e0b26f5d8b73c2ff90782d9c0972620: Si OHCI_PARAM_DEBUG_BUSRESETS (8) está configurado en la máscara de bits del parámetro de depuración, desenmascararemos las interrupciones de reinicio del bus para poder registrarlas. irq_handler registra la interrupción de reinicio del bus. Sin embargo, no podemos borrar el indicador de evento de reinicio del bus en irq_handler porque no atenderemos el evento hasta más tarde. irq_handler sale con el indicador de evento aún configurado. Si la interrupción correspondiente aún está desenmascarada, el primer reinicio del bus generalmente congelará el sistema debido a que se vuelve a llamar a irq_handler cada vez que sale. Esta congelación se puede reproducir cargando firewire_ohci con "modprobe firewire_ohci debug=-1" (para habilitar todos los resultados de depuración). Aparentemente, también hay algunos casos en los que se llamará a bus_reset_work lo suficientemente pronto como para borrar el evento y la operación continuará normalmente. Esta congelación se informó por primera vez unos meses después del commit a007bb85, pero hasta ahora nunca se había solucionado. El nivel de depuración podría establecerse de forma segura en -1 a través de sysfs después de cargar el módulo, pero esto sería ineficaz para registrar las interrupciones de reinicio del bus ya que sólo se desenmascararon durante la inicialización. irq_handler ahora dejará establecido el indicador de evento pero enmascarará las interrupciones de reinicio del bus, por lo que no se volverá a llamar a irq_handler y no se congelará. Si OHCI_PARAM_DEBUG_BUSRESETS está habilitado, bus_reset_work desenmascarará la interrupción después de atender el evento, por lo que las interrupciones futuras se detectarán según se desee. Como efecto secundario de este cambio, OHCI_PARAM_DEBUG_BUSRESETS ahora se puede habilitar a través de sysfs además de durante la carga inicial del módulo. Sin embargo, cuando se habilita a través de sysfs, el registro de interrupciones de reinicio del bus será efectivo solo a partir del segundo reinicio del bus, después de que se haya ejecutado bus_reset_work.

*Credits: N/A
CVSS Scores
Attack Vector
Local
Attack Complexity
Low
Privileges Required
High
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High
* Common Vulnerability Scoring System
SSVC
  • Decision:Track
Exploitation
None
Automatable
No
Tech. Impact
Partial
* Organization's Worst-case Scenario
Timeline
  • 2024-05-30 CVE Reserved
  • 2024-05-30 CVE Published
  • 2024-05-31 EPSS Updated
  • 2024-11-05 CVE Updated
  • ---------- Exploited in Wild
  • ---------- KEV Due Date
  • ---------- First Exploit
CWE
  • CWE-99: Improper Control of Resource Identifiers ('Resource Injection')
CAPEC
Affected Vendors, Products, and Versions
Vendor Product Version Other Status
Vendor Product Version Other Status <-- --> Vendor Product Version Other Status
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
< 4.19.314
Search vendor "Linux" for product "Linux Kernel" and version " < 4.19.314"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
< 5.4.276
Search vendor "Linux" for product "Linux Kernel" and version " < 5.4.276"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
< 5.10.217
Search vendor "Linux" for product "Linux Kernel" and version " < 5.10.217"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
< 5.15.159
Search vendor "Linux" for product "Linux Kernel" and version " < 5.15.159"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
< 6.1.91
Search vendor "Linux" for product "Linux Kernel" and version " < 6.1.91"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
< 6.6.31
Search vendor "Linux" for product "Linux Kernel" and version " < 6.6.31"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
< 6.8.10
Search vendor "Linux" for product "Linux Kernel" and version " < 6.8.10"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
< 6.9
Search vendor "Linux" for product "Linux Kernel" and version " < 6.9"
en
Affected