LiveActive security incident?Get immediate response
CVE Record

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.

UnknownCVSS not scoredNot KEV-listedUpdated
Glexia's TakeAutomated analysismoderate

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.
Prepared
Confidence
medium
Sources
7

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.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

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.

0CVSS vectors
3Timeline events
2ADP providers
6Source links

SSVC decision data

CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: noTechnical Impact: partial

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

ADP provider summaries

CISA-ADPCISA ADP Vulnrichment
other:ssvc
CVECVE Program Container
Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinuxf9f2d957a8ea93c73182aebf7de30935a58c027d, 530cec617f5a8ba6f26bcbf0d64d75c951d17730, fa2bbff7b0b4e211fec5e5686ef96350690597b5, fa2bbff7b0b4e211fec5e5686ef96350690597b5, c4c2345214b66e2505a26fd2ea58839dd7a1d48d, 6.1.75, 6.6.14, 6.7.2unaffected
LinuxLinux6.8, 0, 6.1.103, 6.6.44, 6.10.3, 6.11affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.