// For flags

CVE-2024-26758

md: Don't ignore suspended array in md_check_recovery()

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:

md: Don't ignore suspended array in md_check_recovery()

mddev_suspend() never stop sync_thread, hence it doesn't make sense to
ignore suspended array in md_check_recovery(), which might cause
sync_thread can't be unregistered.

After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following
hang can be triggered by test shell/integrity-caching.sh:

1) suspend the array:
raid_postsuspend
mddev_suspend

2) stop the array:
raid_dtr
md_stop
__md_stop_writes
stop_sync_thread
set_bit(MD_RECOVERY_INTR, &mddev->recovery);
md_wakeup_thread_directly(mddev->sync_thread);
wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery))

3) sync thread done:
md_do_sync
set_bit(MD_RECOVERY_DONE, &mddev->recovery);
md_wakeup_thread(mddev->thread);

4) daemon thread can't unregister sync thread:
md_check_recovery
if (mddev->suspended)
return; -> return directly
md_read_sync_thread
clear_bit(MD_RECOVERY_RUNNING, &mddev->recovery);
-> MD_RECOVERY_RUNNING can't be cleared, hence step 2 hang;

This problem is not just related to dm-raid, fix it by ignoring
suspended array in md_check_recovery(). And follow up patches will
improve dm-raid better to frozen sync thread during suspend.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md: No ignorar la matriz suspendida en md_check_recovery() mddev_suspend() nunca detiene sync_thread, por lo tanto, no tiene sentido ignorar la matriz suspendida en md_check_recovery(), lo que podría causar sync_thread no se puede cancelar el registro. Después de commit f52f5c71f3d4 ("md: arreglar la detención del hilo de sincronización"), el siguiente bloqueo se puede activar mediante test shell/integrity-caching.sh: 1) suspender la matriz: raid_postsuspend mddev_suspend 2) detener la matriz: raid_dtr md_stop __md_stop_writes stop_sync_thread set_bit(MD_RECOVERY_INTR , &mddev->recuperación); md_wakeup_thread_directly(mddev->sync_thread); wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) 3) hilo de sincronización realizado: md_do_sync set_bit(MD_RECOVERY_DONE, &mddev->recovery); md_wakeup_thread(mddev->thread); 4) el hilo del demonio no puede cancelar el registro del hilo de sincronización: md_check_recovery si (mddev->suspended) regresa; -> devolver directamente md_read_sync_thread clear_bit(MD_RECOVERY_RUNNING, &mddev->recovery); -> MD_RECOVERY_RUNNING no se puede borrar, por lo tanto el paso 2 se bloquea; Este problema no solo está relacionado con dm-raid; solucionelo ignorando la matriz suspendida en md_check_recovery(). Y los parches de seguimiento mejorarán mejor dm-raid para congelar el hilo de sincronización durante la suspensión.

*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-02-19 CVE Reserved
  • 2024-04-03 CVE Published
  • 2024-04-04 EPSS Updated
  • 2024-08-02 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"
>= 3.0 < 6.7.7
Search vendor "Linux" for product "Linux Kernel" and version " >= 3.0 < 6.7.7"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 3.0 < 6.8
Search vendor "Linux" for product "Linux Kernel" and version " >= 3.0 < 6.8"
en
Affected