CVE-2024-43855: md: fix deadlock between mddev_suspend and flush bio
In the Linux kernel, the following vulnerability has been resolved:
md: fix deadlock between mddev_suspend and flush bio
Deadlock occurs when mddev is being suspended while some flush bio is in
progress. It is a complex issue.
T1. the first flush is at the ending stage, it clears 'mddev->flush_bio'
and tries to submit data, but is blocked because mddev is suspended
by T4.
T2. the second flush sets 'mddev->flush_bio', and attempts to queue
md_submit_flush_data(), which is already running (T1) and won't
execute again if on the same CPU as T1.
T3. the third flush inc active_io and tries to flush, but is blocked because
'mddev->flush_bio' is not NULL (set by T2).
T4. mddev_suspend() is called and waits for active_io dec to 0 which is inc
by T3.
T1 T2 T3 T4
(flush 1) (flush 2) (third 3) (suspend)
md_submit_flush_data
mddev->flush_bio = NULL;
.
. md_flush_request
. mddev->flush_bio = bio
. queue submit_flushes
. .
. . md_handle_request
. . active_io + 1
. . md_flush_request
. . wait !mddev->flush_bio
. .
. . mddev_suspend
. . wait !active_io
. .
. submit_flushes
. queue_work md_submit_flush_data
. //md_submit_flush_data is already running (T1)
.
md_handle_request
wait resume
The root issue is non-atomic inc/dec of active_io during flush process.
active_io is dec before md_submit_flush_data is queued, and inc soon
after md_submit_flush_data() run.
md_flush_request
active_io + 1
submit_flushes
active_io - 1
md_submit_flush_data
md_handle_request
active_io + 1
make_request
active_io - 1
If active_io is dec after md_handle_request() instead of within
submit_flushes(), make_request() can be called directly intead of
md_handle_request() in md_submit_flush_data(), and active_io will
only inc and dec once in the whole flush process. Deadlock will be
fixed.
Additionally, the only difference between fixing the issue and before is
that there is no return error handling of make_request(). But after
previous patch cleaned md_write_start(), make_requst() only return error
in raid5_make_request() by dm-raid, see commit 41425f96d7aa ("dm-raid456,
md/raid456: fix a deadlock for dm-raid456 while io concurrent with
reshape)". Since dm always splits data and flush operation into two
separate io, io size of flush submitted by dm always is 0, make_request()
will not be called in md_submit_flush_data(). To prevent future
modifications from introducing issues, add WARN_ON to ensure
make_request() no error is returned in this context.
Security readout for executives and security teams
Plain-English summary
CVE-2024-43855 is a Linux kernel storage bug that can deadlock md RAID handling during flush and suspend activity. The likely business impact is availability: affected systems may hang storage I/O until recovery or reboot. Sources do not show active exploitation or a remote attack path.
Executive priority
Treat as a routine but important availability fix for Linux storage infrastructure. It does not currently justify emergency response without affected md usage or vendor severity escalation, but delaying kernel updates may leave critical storage hosts vulnerable to hard-to-diagnose hangs.
Technical view
The Linux md subsystem can deadlock when mddev_suspend waits for active_io while concurrent flush bios hold flush_bio state. The upstream fix changes active_io accounting so flush processing increments and decrements once, and adds a warning for unexpected make_request errors.
Likely exposure
Exposure is most relevant to Linux systems using the md multi-device storage subsystem, including RAID-related configurations. The supplied version data is incomplete for distro mapping, so teams should validate against their kernel vendor advisories and installed kernel changelogs.
Exploitation context
The source bundle reports no KEV listing and provides no evidence of active exploitation. The described failure requires specific concurrent storage flush and suspend timing, suggesting operational denial of service rather than straightforward remote compromise.
Researcher notes
The evidence supports a kernel concurrency defect, not memory corruption or privilege escalation. The CVE record’s version data is commit-heavy and not enough for precise distro exposure. Research should focus on kernel lineage, md usage, and whether downstream vendors backported the stable fix.
Mitigation direction
Apply Linux kernel or distribution updates that include the referenced stable fixes.
Check Debian LTS guidance if running Debian LTS kernels.
Prioritize storage servers, virtualization hosts, and appliances using Linux md RAID.
If no vendor advisory exists, monitor vendor guidance for CVE-2024-43855.
Plan maintenance windows because kernel fixes usually require rebooting.
Validation and detection
Identify systems running Linux kernels with md RAID or related storage configurations.
Check installed kernel changelogs for CVE-2024-43855 or referenced stable commits.
Confirm vendor fixed-version mapping for each distribution and appliance build.
Review incident logs for storage hangs during md suspend or flush activity.
Verify patched systems boot the intended fixed kernel after maintenance.
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-43855 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.