0.0
NA
CVE-2024-36950
FireWire OHCI Unmasked Bus Reset Interrupt Freeze
Description

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.

INFO

Published Date :

May 30, 2024, 4:15 p.m.

Last Modified :

June 27, 2024, 2:15 p.m.

Source :

416baaa9-dc9f-4396-8d5f-8c081fb06d67

Remotely Exploitable :

No

Impact Score :

Exploitability Score :

Affected Products

The following products are affected by CVE-2024-36950 vulnerability. Even if cvefeed.io is aware of the exact versions of the products that are affected, the information is not represented in the table below.

ID Vendor Product Action
1 Linux linux_kernel

We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).

Results are limited to the first 15 repositories due to potential performance issues.

The following list is the news that have been mention CVE-2024-36950 vulnerability anywhere in the article.

The following table lists the changes that have been made to the CVE-2024-36950 vulnerability over time.

Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.

  • CVE Modified by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

    Jun. 27, 2024

    Action Type Old Value New Value
    Added Reference kernel.org https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html [No types assigned]
  • CVE Modified by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

    Jun. 27, 2024

    Action Type Old Value New Value
    Added Reference kernel.org https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html [No types assigned]
  • CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

    May. 30, 2024

    Action Type Old Value New Value
    Added Description 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.
    Added Reference kernel.org https://git.kernel.org/stable/c/b3948c69d60279fce5b2eeda92a07d66296c8130 [No types assigned]
    Added Reference kernel.org https://git.kernel.org/stable/c/31279bbca40d2f40cb3bbb6d538ec9620a645dec [No types assigned]
    Added Reference kernel.org https://git.kernel.org/stable/c/fa273f312334246c909475c5868e6daab889cc8c [No types assigned]
    Added Reference kernel.org https://git.kernel.org/stable/c/4f9cc355c328fc4f41cbd9c4cd58b235184fa420 [No types assigned]
    Added Reference kernel.org https://git.kernel.org/stable/c/6fafe3661712b143d9c69a7322294bd53f559d5d [No types assigned]
    Added Reference kernel.org https://git.kernel.org/stable/c/5982887de60c1b84f9c0ca07c835814d07fd1da0 [No types assigned]
    Added Reference kernel.org https://git.kernel.org/stable/c/8643332aac0576581cfdf01798ea3e4e0d624b61 [No types assigned]
    Added Reference kernel.org https://git.kernel.org/stable/c/752e3c53de0fa3b7d817a83050b6699b8e9c6ec9 [No types assigned]
EPSS is a daily estimate of the probability of exploitation activity being observed over the next 30 days. Following chart shows the EPSS score history of the vulnerability.
CWE - Common Weakness Enumeration

While CVE identifies specific instances of vulnerabilities, CWE categorizes the common flaws or weaknesses that can lead to vulnerabilities. CVE-2024-36950 is associated with the following CWEs:

Common Attack Pattern Enumeration and Classification (CAPEC)

Common Attack Pattern Enumeration and Classification (CAPEC) stores attack patterns, which are descriptions of the common attributes and approaches employed by adversaries to exploit the CVE-2024-36950 weaknesses.

NONE - Vulnerability Scoring System