// For flags

CVE-2023-52589

media: rkisp1: Fix IRQ disable race issue

Severity Score

"-"
*CVSS v-

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:

media: rkisp1: Fix IRQ disable race issue

In rkisp1_isp_stop() and rkisp1_csi_disable() the driver masks the
interrupts and then apparently assumes that the interrupt handler won't
be running, and proceeds in the stop procedure. This is not the case, as
the interrupt handler can already be running, which would lead to the
ISP being disabled while the interrupt handler handling a captured
frame.

This brings up two issues: 1) the ISP could be powered off while the
interrupt handler is still running and accessing registers, leading to
board lockup, and 2) the interrupt handler code and the code that
disables the streaming might do things that conflict.

It is not clear to me if 2) causes a real issue, but 1) can be seen with
a suitable delay (or printk in my case) in the interrupt handler,
leading to board lockup.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: rkisp1: Solucionar el problema de ejecución de desactivación de IRQ En rkisp1_isp_stop() y rkisp1_csi_disable() el controlador enmascara las interrupciones y aparentemente asume que el controlador de interrupciones no se ejecutará y continúa en el procedimiento de parada. Este no es el caso, ya que el controlador de interrupciones puede estar ejecutándose, lo que llevaría a que el ISP se deshabilite mientras el controlador de interrupciones maneja una trama capturada. Esto plantea dos problemas: 1) el ISP podría apagarse mientras el controlador de interrupciones aún está ejecutándose y accediendo a los registros, lo que provoca el bloqueo de la placa, y 2) el código del controlador de interrupciones y el código que deshabilita la transmisión pueden hacer cosas que entren en conflicto. No me queda claro si 2) causa un problema real, pero 1) se puede ver con un retraso adecuado (o printk en mi caso) en el controlador de interrupciones, lo que provoca el bloqueo de la placa.

*Credits: N/A
CVSS Scores
Attack Vector
-
Attack Complexity
-
Privileges Required
-
User Interaction
-
Scope
-
Confidentiality
-
Integrity
-
Availability
-
* Common Vulnerability Scoring System
SSVC
  • Decision:Track
Exploitation
None
Automatable
No
Tech. Impact
Partial
* Organization's Worst-case Scenario
Timeline
  • 2024-03-02 CVE Reserved
  • 2024-03-06 CVE Published
  • 2024-03-06 EPSS Updated
  • 2024-12-19 CVE Updated
  • ---------- Exploited in Wild
  • ---------- KEV Due Date
  • ---------- First Exploit
CWE
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"
 >= 5.6 < 6.1.77
Search vendor "Linux" for product "Linux Kernel" and version " >= 5.6 < 6.1.77"
en
Affected
Linux
Search vendor "Linux"
 Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
 >= 5.6 < 6.6.16
Search vendor "Linux" for product "Linux Kernel" and version " >= 5.6 < 6.6.16"
en
Affected
Linux
Search vendor "Linux"
 Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
 >= 5.6 < 6.7.4
Search vendor "Linux" for product "Linux Kernel" and version " >= 5.6 < 6.7.4"
en
Affected
Linux
Search vendor "Linux"
 Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
 >= 5.6 < 6.8
Search vendor "Linux" for product "Linux Kernel" and version " >= 5.6 < 6.8"
en
Affected