CVE-2024-36950

MEDIUM
Published May 30, 2024 Modified Dec 17, 2025

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.

Is your site exposed to CVE-2024-36950?

Run a free security scan — no signup, results in seconds.

CVSS v3.1 Score

4.4
MEDIUM
CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H

Affected Products

Vendor Product
linux linux_kernel
linux linux_kernel
linux linux_kernel
linux linux_kernel
linux linux_kernel
linux linux_kernel
linux linux_kernel
linux linux_kernel
linux linux_kernel
debian debian_linux

References

Advisories & Patches

https://git.kernel.org/stable/c/31279bbca40d2f40cb3bbb6d538ec9620a645dec https://git.kernel.org/stable/c/4f9cc355c328fc4f41cbd9c4cd58b235184fa420 https://git.kernel.org/stable/c/5982887de60c1b84f9c0ca07c835814d07fd1da0 https://git.kernel.org/stable/c/6fafe3661712b143d9c69a7322294bd53f559d5d https://git.kernel.org/stable/c/752e3c53de0fa3b7d817a83050b6699b8e9c6ec9 https://git.kernel.org/stable/c/8643332aac0576581cfdf01798ea3e4e0d624b61 https://git.kernel.org/stable/c/b3948c69d60279fce5b2eeda92a07d66296c8130 https://git.kernel.org/stable/c/fa273f312334246c909475c5868e6daab889cc8c https://git.kernel.org/stable/c/31279bbca40d2f40cb3bbb6d538ec9620a645dec https://git.kernel.org/stable/c/4f9cc355c328fc4f41cbd9c4cd58b235184fa420 https://git.kernel.org/stable/c/5982887de60c1b84f9c0ca07c835814d07fd1da0 https://git.kernel.org/stable/c/6fafe3661712b143d9c69a7322294bd53f559d5d https://git.kernel.org/stable/c/752e3c53de0fa3b7d817a83050b6699b8e9c6ec9 https://git.kernel.org/stable/c/8643332aac0576581cfdf01798ea3e4e0d624b61 https://git.kernel.org/stable/c/b3948c69d60279fce5b2eeda92a07d66296c8130 https://git.kernel.org/stable/c/fa273f312334246c909475c5868e6daab889cc8c

Frequently Asked Questions

What is CVE-2024-36950? +
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. It has a CVSS v3.1 base score of 4.4 (MEDIUM).
How severe is CVE-2024-36950? +
CVE-2024-36950 has a CVSS v3.1 score of 4.4 out of 10, rated MEDIUM. This is a medium-severity vulnerability that should be remediated as part of regular maintenance.
What products are affected by CVE-2024-36950? +
CVE-2024-36950 affects products from debian, linux, specifically: debian_linux, linux_kernel. Check the affected products table above for specific version ranges.
How do I check if I'm vulnerable to CVE-2024-36950? +
You can use Secably's free Website Scanner to check your website for known vulnerabilities. For infrastructure scanning, use the Port Scanner to identify exposed services that may be affected. Check the vendor advisories linked above for specific patch and version information.

Related Vulnerabilities

CVE-2025-9588 10.0

Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') vulnerability in Iron Mountain Archiving Services Inc. …
CVE-2025-57870 10.0

A SQL Injection vulnerability exists in Esri ArcGIS Server versions 11.3, 11.4 and 11.5 on Windows, Linux and Kubernetes. This …
CVE-2026-48286 10.0

Adobe Campaign Classic (ACC) versions 7.4.3 build 9396 and earlier are affected by an Incorrect Authorization vulnerability that could result …
CVE-2026-13782 10.0

Use after free in Browser in Google Chrome prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer …
CVE-2026-48449 10.0

Adobe Campaign Classic (ACC) is affected by an Incorrect Authorization vulnerability that could result in arbitrary code execution in the …
CVE-2026-48303 10.0

Adobe Campaign Classic (ACC) versions 7.4.3 build 9394 and earlier are affected by an Incorrect Authorization vulnerability that could result …

Don't wait for an exploit

Scan your website for vulnerabilities like CVE-2024-36950 — free, no signup required.