// For flags

CVE-2024-26756

md: Don't register sync_thread for reshape directly

Severity Score

5.5
*CVSS v3

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 register sync_thread for reshape directly Currently, if reshape is interrupted, then reassemble the array will
register sync_thread directly from pers->run(), in this case
'MD_RECOVERY_RUNNING' is set directly, however, there is no guarantee
that md_do_sync() will be executed, hence stop_sync_thread() will hang
because 'MD_RECOVERY_RUNNING' can't be cleared. Last patch make sure that md_do_sync() will set MD_RECOVERY_DONE,
however, following hang can still be triggered by dm-raid test
shell/lvconvert-raid-reshape.sh occasionally: [root@fedora ~]# cat /proc/1982/stack
[<0>] stop_sync_thread+0x1ab/0x270 [md_mod]
[<0>] md_frozen_sync_thread+0x5c/0xa0 [md_mod]
[<0>] raid_presuspend+0x1e/0x70 [dm_raid]
[<0>] dm_table_presuspend_targets+0x40/0xb0 [dm_mod]
[<0>] __dm_destroy+0x2a5/0x310 [dm_mod]
[<0>] dm_destroy+0x16/0x30 [dm_mod]
[<0>] dev_remove+0x165/0x290 [dm_mod]
[<0>] ctl_ioctl+0x4bb/0x7b0 [dm_mod]
[<0>] dm_ctl_ioctl+0x11/0x20 [dm_mod]
[<0>] vfs_ioctl+0x21/0x60
[<0>] __x64_sys_ioctl+0xb9/0xe0
[<0>] do_syscall_64+0xc6/0x230
[<0>] entry_SYSCALL_64_after_hwframe+0x6c/0x74 Meanwhile mddev->recovery is:
MD_RECOVERY_RUNNING |
MD_RECOVERY_INTR |
MD_RECOVERY_RESHAPE |
MD_RECOVERY_FROZEN Fix this problem by remove the code to register sync_thread directly
from raid10 and raid5. And let md_check_recovery() to register
sync_thread.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md: No registre sync_thread para remodelar directamente Actualmente, si se interrumpe el proceso de remodelación, volver a ensamblar la matriz registrará sync_thread directamente desde pers-&gt;run(), en este caso 'MD_RECOVERY_RUNNING ' se configura directamente, sin embargo, no hay garantía de que md_do_sync() se ejecute, por lo tanto, stop_sync_thread() se bloqueará porque 'MD_RECOVERY_RUNNING' no se puede borrar. En el último parche, asegúrese de que md_do_sync() establezca MD_RECOVERY_DONE; sin embargo, dm-raid test shell/lvconvert-raid-reshape.sh ocasionalmente puede activar el siguiente bloqueo: [root@fedora ~]# cat /proc/1982/stack [&lt;0&gt;] stop_sync_thread+0x1ab/0x270 [md_mod] [&lt;0&gt;] md_frozen_sync_thread+0x5c/0xa0 [md_mod] [&lt;0&gt;] raid_presuspend+0x1e/0x70 [dm_raid] [&lt;0&gt;] dm_table_presuspend_targets+0x40/0xb0 [ dm_mod] [&lt;0&gt;] __dm_destroy+0x2a5/0x310 [dm_mod] [&lt;0&gt;] dm_destroy+0x16/0x30 [dm_mod] [&lt;0&gt;] dev_remove+0x165/0x290 [dm_mod] [&lt;0&gt;] ctl_ioctl+0x4bb/ 0x7b0 [dm_mod] [&lt;0&gt;] dm_ctl_ioctl+0x11/0x20 [dm_mod] [&lt;0&gt;] vfs_ioctl+0x21/0x60 [&lt;0&gt;] __x64_sys_ioctl+0xb9/0xe0 [&lt;0&gt;] do_syscall_64+0xc6/0x230 [&lt;0 &gt;] Entry_SYSCALL_64_after_hwframe+0x6c/0x74 Mientras tanto mddev-&gt;recovery es: MD_RECOVERY_RUNNING | MD_RECOVERY_INTR | MD_RECOVERY_RESHAPE | MD_RECOVERY_FROZEN Solucione este problema eliminando el código para registrar sync_thread directamente desde raid10 y raid5. Y deje que md_check_recovery() registre sync_thread.

In the Linux kernel, the following vulnerability has been resolved: md: Don't register sync_thread for reshape directly Currently, if reshape is interrupted, then reassemble the array will register sync_thread directly from pers->run(), in this case 'MD_RECOVERY_RUNNING' is set directly, however, there is no guarantee that md_do_sync() will be executed, hence stop_sync_thread() will hang because 'MD_RECOVERY_RUNNING' can't be cleared. Last patch make sure that md_do_sync() will set MD_RECOVERY_DONE, however, following hang can still be triggered by dm-raid test shell/lvconvert-raid-reshape.sh occasionally: [root@fedora ~]# cat /proc/1982/stack [<0>] stop_sync_thread+0x1ab/0x270 [md_mod] [<0>] md_frozen_sync_thread+0x5c/0xa0 [md_mod] [<0>] raid_presuspend+0x1e/0x70 [dm_raid] [<0>] dm_table_presuspend_targets+0x40/0xb0 [dm_mod] [<0>] __dm_destroy+0x2a5/0x310 [dm_mod] [<0>] dm_destroy+0x16/0x30 [dm_mod] [<0>] dev_remove+0x165/0x290 [dm_mod] [<0>] ctl_ioctl+0x4bb/0x7b0 [dm_mod] [<0>] dm_ctl_ioctl+0x11/0x20 [dm_mod] [<0>] vfs_ioctl+0x21/0x60 [<0>] __x64_sys_ioctl+0xb9/0xe0 [<0>] do_syscall_64+0xc6/0x230 [<0>] entry_SYSCALL_64_after_hwframe+0x6c/0x74 Meanwhile mddev->recovery is: MD_RECOVERY_RUNNING | MD_RECOVERY_INTR | MD_RECOVERY_RESHAPE | MD_RECOVERY_FROZEN Fix this problem by remove the code to register sync_thread directly from raid10 and raid5. And let md_check_recovery() to register sync_thread.

*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
Attack Vector
Local
Attack Complexity
Low
Authentication
Single
Confidentiality
None
Integrity
None
Availability
Complete
* 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
  • 2025-05-04 CVE Updated
  • 2025-06-29 EPSS 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"
>= 2.6.17 < 6.7.7
Search vendor "Linux" for product "Linux Kernel" and version " >= 2.6.17 < 6.7.7"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 2.6.17 < 6.8
Search vendor "Linux" for product "Linux Kernel" and version " >= 2.6.17 < 6.8"
en
Affected