CVE-2024-26756: md: Don't register sync_thread for reshape directly
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.
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel storage reliability flaw affecting md RAID reshape handling. Under specific interrupted reshape conditions, the system can hang while stopping a RAID sync thread. The public record does not show data theft, privilege escalation, or active exploitation, but affected storage hosts could experience operational disruption.
Executive priority
Treat this as a targeted reliability risk for Linux storage infrastructure, not a broad emergency. Patch through normal kernel maintenance, escalating priority for systems actively using RAID reshape or dm-raid operations.
Technical view
In the md RAID subsystem, raid5 and raid10 could register sync_thread directly during reassembly after an interrupted reshape. That sets MD_RECOVERY_RUNNING without guaranteeing md_do_sync() runs, leaving the flag uncleared and causing stop_sync_thread() to hang. The fix moves sync_thread registration to md_check_recovery().
Likely exposure
Exposure is most relevant to Linux systems using md RAID or dm-raid reshape workflows. The source lists Linux kernel versions including 2.6.17, 6.7.7, and 6.8 as affected, with stable kernel fixes referenced.
Exploitation context
The source describes an occasional hang reproduced by a dm-raid reshape test. There is no KEV listing and no cited evidence of active exploitation. Remote exploitability is not established by the provided sources.
Researcher notes
Evidence supports a denial-of-service style kernel hang in md recovery state handling. Public details are implementation-focused and do not provide CVSS, CWE, or exploitation evidence. Avoid assuming impact beyond availability without additional vendor analysis.
Mitigation direction
Review Linux distribution advisories for CVE-2024-26756 kernel updates.
Prioritize updates on hosts using md RAID or dm-raid reshape operations.
Apply kernel builds containing the referenced stable md fixes.
Schedule RAID reshape or maintenance work after patching where practical.
If patching is delayed, monitor for md or dm-raid hangs during reshape workflows.
Validation and detection
Inventory Linux systems using md RAID, raid5, raid10, or dm-raid.
Check running kernel versions against vendor advisories for CVE-2024-26756.
Confirm deployed kernels include the referenced stable commits or downstream backports.
Review logs for interrupted reshape, frozen recovery, or md sync thread hangs.
Validate RAID maintenance procedures after kernel update in a test window.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-26756 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.