// For flags

CVE-2024-26899

block: fix deadlock between bd_link_disk_holder and partition scan

Severity Score

5.5
*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:

block: fix deadlock between bd_link_disk_holder and partition scan

'open_mutex' of gendisk is used to protect open/close block devices. But
in bd_link_disk_holder(), it is used to protect the creation of symlink
between holding disk and slave bdev, which introduces some issues.

When bd_link_disk_holder() is called, the driver is usually in the process
of initialization/modification and may suspend submitting io. At this
time, any io hold 'open_mutex', such as scanning partitions, can cause
deadlocks. For example, in raid:

T1 T2
bdev_open_by_dev
lock open_mutex [1]
...
efi_partition
...
md_submit_bio
md_ioctl mddev_syspend
-> suspend all io
md_add_new_disk
bind_rdev_to_array
bd_link_disk_holder
try lock open_mutex [2]
md_handle_request
-> wait mddev_resume

T1 scan partition, T2 add a new device to raid. T1 waits for T2 to resume
mddev, but T2 waits for open_mutex held by T1. Deadlock occurs.

Fix it by introducing a local mutex 'blk_holder_mutex' to replace
'open_mutex'.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: soluciona el punto muerto entre bd_link_disk_holder y el análisis de partición. 'open_mutex' de gendisk se utiliza para proteger dispositivos de bloqueo de apertura/cierre. Pero en bd_link_disk_holder(), se utiliza para proteger la creación de un enlace simbólico entre el disco de retención y el bdev esclavo, lo que introduce algunos problemas. Cuando se llama a bd_link_disk_holder(), el controlador generalmente está en el proceso de inicialización/modificación y puede suspender el envío de io. En este momento, cualquier retención de io 'open_mutex', como escanear particiones, puede causar interbloqueos. Por ejemplo, en raid: T1 T2 bdev_open_by_dev lock open_mutex [1] ... efi_partition ... md_submit_bio md_ioctl mddev_syspend -> suspender todo io md_add_new_disk bind_rdev_to_array bd_link_disk_holder try lock open_mutex [2] md_handle_request -> esperar mddev_resume T1 escanear partición, agregar un Nuevo dispositivo para atacar. T1 espera a que T2 reanude mddev, pero T2 espera a open_mutex retenido por T1. Se produce un punto muerto. Solucionarlo introduciendo un mutex local 'blk_holder_mutex' para reemplazar 'open_mutex'.

*Credits: N/A
CVSS Scores
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
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-02-19 CVE Reserved
  • 2024-04-17 CVE Published
  • 2024-04-30 EPSS Updated
  • 2024-08-02 CVE Updated
  • ---------- Exploited in Wild
  • ---------- KEV Due Date
  • ---------- First Exploit
CWE
  • CWE-667: Improper Locking
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"
>= 6.7 < 6.7.11
Search vendor "Linux" for product "Linux Kernel" and version " >= 6.7 < 6.7.11"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 6.7 < 6.8.2
Search vendor "Linux" for product "Linux Kernel" and version " >= 6.7 < 6.8.2"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 6.7 < 6.9
Search vendor "Linux" for product "Linux Kernel" and version " >= 6.7 < 6.9"
en
Affected