Linux md/md bitmap bug CVE-2025-22124 fixes clustermd hangs in stable kernels

A subtle arithmetic bug in the Linux kernel’s md/md-bitmap code — tracked as CVE‑2025‑22124 — can leave a clustermd node’s first superblock page unwritten and cause a deterministic hang in mdadm’s clustermd test suite, and the fix is now in upstream stable trees; operators should treat this as a medium‑severity availability issue and patch affected kernels promptly.

Background / Overview​

The Linux MD (multiple‑device) subsystem implements software RAID and includes the md‑bitmap facility, which maintains write‑intent bitmaps used to track changes when arrays are synchronized or when cluster‑aware RAID (clustermd) coordinates work across nodes. In clustermd, bitmaps and superblocks are laid out so that each cluster node stores its own write‑intent bitmap and a small per‑node superblock area. A bug in the index arithmetic used when writing superblock pages could result in computing a zero‑length write for the first 4 KB superblock region of certain nodes, so that filemap_write_page is never called for that page — a condition that leads to a reproducible hang in mdadm/clustermd_tests/01r1_Grow_resize. The vulnerability and the applied fix are documented in public vulnerability trackers and in the upstream kernel stable commits. This is primarily an availability (denial‑of‑service) defect: there is no public evidence it leads to information disclosure or remote code execution, but the impact on storage operations can be severe for hosts that run clustermd or otherwise exercise the md bitmap superblock paths. Multiple distribution advisories and vulnerability databases have indexed the CVE and mapped fixes to kernel stable backports; the affected kernel ranges and vendor package mappings vary by distribution.

---

What exactly went wrong — technical anatomy​

Bitmap layout and the off‑by‑index problem​

In clustermd, the layout for write‑intent bitmaps and superblocks interleaves small superblock regions with bitmap data for each cluster node. The on‑disk layout conceptually looks like:

• 0: idle region
• 4 KB: md super
• subsequent pages: per‑node bm super and bitmap bits interleaved by node

In one code path — within __write_sb_page — the code computed a page index relative to the full bitmap storage region and then calculated a bitmap_limit used to size the md_super_write call. If pg_index for a node equaled bitmap->storage.file_pages, the existing arithmetic produced bitmap_limit == 0. That led to md_super_write being invoked with size 0, so the first 4 KB superblock region for that node was never written via filemap_write_page. The result: a deterministic test hang during specific clustermd tests that expect the superblock to be updated. The upstream fix changes the calculation to use pg_index % bitmap->storage.file_pages so the bitmap_limit calculation is correct across the node partitioning.

Why the hang occurs (behavioral sequence)​

• A clustermd superblock write path computes which pages to write based on pg_index and bitmap->storage.file_pages.
• For certain pg_index values (equal to file_pages), bitmap_limit was computed as zero.
• The md_super_write call ran with a zero size and skipped writing the intended page.
• Later operations that expect the superblock change to be present block, waiting on progress or states that now cannot be achieved because the on‑disk superblock remained stale.
• The test harness (and some real operational sequences) therefore hang in places where filemap/writes and subsequent rollup logic expect the superblock to be updated.

This is a logic / bounds arithmetic mistake rather than a memory‑corruption or use‑after‑free; but because it affects on‑disk metadata and synchronization flows, its operational consequences are significant for availability.

---

Affected kernels and severity​

Multiple authoritative trackers list the CVE and map affected kernel versions. The National Vulnerability Database (NVD) lists affected CPE ranges in practical kernel series and assigns a CVSS v3.1 base of 5.5 (Medium) with vector AV:L/AC:L/PR:L/A:H — reflecting a local attack vector that impacts availability. Vendor trackers show some variation in scoring (Amazon’s ALAS mapping used a CVSS 6.0 rating in its ecosystem), so organizations should prioritize according to exposure and their operational risk model. The NVD entry maps concrete CPE ranges that were reported as affected during initial analysis (for example, several 6.x stable series ranges are listed before specific stable backports). Distributions have relied on upstream stable commits to create backported fixes for their kernel packages; refer to your vendor advisories for the exact package names and fixed builds. Cross‑reference evidence: OSV, Debian, Ubuntu, SUSE, Red Hat and other trackers each contain summaries that corroborate the same failure mode and remediation strategy — the fix is a one‑line arithmetic correction and related defensive checks landed in the stable kernel trees. This cross‑validation reduces the chance of mischaracterizing the bug.

---

The upstream fix (what maintainers changed)​

Kernel maintainers applied a targeted correction: instead of using the raw pg_index value that could match bitmap->storage.file_pages and produce an edge‑case zero limit, the code now computes the node‑relative index by taking pg_index modulo bitmap->storage.file_pages. That change ensures bitmap_limit is never incorrectly computed as zero for the node’s first page, and md_super_write receives the correct size to cause filemap_write_page to update the superblock area as expected. The patch is intentionally small and local to the md/md‑bitmap write path and was merged into stable backports; kernel stable commit references appear in public vulnerability databases. Why this approach is sensible:

• It corrects the arithmetic at the point of error, preserving all other semantics.
• The change is low‑risk and easy to backport to vendor kernels.
• Because the root cause is an index arithmetic bug rather than a redesign issue, the minimal fix is preferable to large refactors that increase regression risk.

---

Real‑world impact and attack model​

This vulnerability is a local denial‑of‑service primitive. The threat model assumes an attacker or misbehaving process with the ability to provoke clustermd write flows or the md bitmap superblock path — this typically requires local access or control over image supply and device operations (for example, CI systems or host processes that mount or manipulate block device images). Practical high‑risk scenarios include:

• Shared infrastructure and multi‑tenant hosts where untrusted containers or tenants can trigger md operations.
• Virtualization hosts and CI/image‑ingestion systems that manipulate loopback block devices or perform automated reshape/grow operations.
• Test labs or automated deployment systems that run clustermd tests or otherwise exercise the write‑intent bitmap flows.

Privilege and access: most public advisories model this as local with low complexity; the actual privileges required depend on how administrative tooling and device nodes are exposed in your environment. In strict server setups the operations may require elevated privileges, but in many automated or misconfigured environments lower privileges can exercise the path. Notably, the impact is operational — not a direct confidentiality or integrity breach — yet the effect on availability can be severe (hung mdadm operations, blocked array stop/start, stalled reshapes). The reproducible test failure in mdadm/clustermd_tests/01r1_Grow_resize is evidence the condition is deterministic under the right timing and data layout, making it suitable for both accidental trigger and deliberate misuse.

---

Detection, indicators and forensic signals​

If you suspect this issue has occurred in an environment, these signals are useful to triage:

• Hung mdadm operations or clustermd test failures that stall at superblock write or array resize operations.
• Kernel logs that show filemap write operations skipping expected page writes in md bitmap paths.
• Reproducible failures in mdadm/clustermd_tests/01r1_Grow_resize or similar test harnesses that exercise clustermd write flows.
• Long‑running or blocked I/O operations on md devices following reshape/grow sequences.

When investigating, preserve kernel logs (dmesg, journalctl -k), mdadm logs and any test harness output. If you need to reproduce the hang for diagnostics, only do so in isolated lab systems with no production data at risk. Several distribution advisories and public writeups include suggested reproduction steps for the clustermd test case; use vendor guidance and test harnesses in a controlled manner.

---

Remediation and operational playbook​

Patch promptly: the definitive remediation is to install a kernel update from your distribution that includes the upstream stable commit(s) that correct the bitmap index calculation. Vendor advisories (Ubuntu, Debian, SUSE, Red Hat, Amazon, Oracle Linux, etc. have mapped fixed kernel package versions; follow those advisories to select the correct package for your release. Validate that the kernel changelog references the md/md‑bitmap fix or the upstream commit IDs before rolling out widely. A practical rollout checklist:

• Inventory: run uname -r on all Linux hosts to collect kernel versions; identify hosts running md arrays: cat /proc/mdstat and lsmod | grep md.
• Map: consult your vendor’s security advisory or package changelog to determine which kernel package contains the backported fix for your distribution and release.
• Pilot: stage the updated kernel on a pilot subset (especially storage hosts and multi‑tenant nodes) and exercise mdadm/clustermd operational flows in a sandbox.
• Deploy: schedule maintenance windows, install the updated kernel, and reboot into the patched image (or apply vendor livepatch if validated and available).
• Validate: rerun the relevant test harnesses and monitor kernel logs for residual errors; confirm the mdadm/clustermd_tests/01r1_Grow_resize scenario no longer hangs.
• Monitor: maintain post‑patch monitoring of storage subsystems for several days to ensure no latent issues surface.

Short‑term mitigations if immediate patching is impossible:

• Avoid running operations that exercise clustermd superblock writes and automated resize/reshape activities on vulnerable hosts.
• Restrict who can run mdadm, manipulate device‑mapper mappings or perform cluster‑node operations.
• Isolate or avoid exposing device management to untrusted containers or guests to reduce exploitation surface.

---

Vendor responses and backports​

Major distributions and upstream trackers indexed the CVE and provided advisory mappings and fixed package releases:

• Ubuntu published a CVE advisory and prioritized the kernel updates for affected series.
• Debian, SUSE and other vendors listed the CVE with their own DSA/errata entries and backported fixes.
• Cloud and enterprise distributions (Amazon ALAS, Oracle Linux, Red Hat) also tracked the issue and tied fixes to kernel packages or recommended updates for specific release streams. Vendor severity labels and CVSS scoring showed some variation across ecosystems.

Because vendors backport stable commits differently, the concrete package name and version that fixes the vulnerability vary by distribution and kernel branch. Operators must consult their vendor security tracker for the authoritative package mapping for their environment.

---

Risk assessment — strengths and residual caveats​

Strengths of the public handling:

• The fix is small, focused and low‑risk — a single arithmetic correction that restores correct page index calculation. That makes stable backports straightforward and reduces regression risk.
• Multiple independent trackers (NVD, OSV, vendor advisories) and the upstream stable commit references provide a consistent public record, making it easier for administrators to validate vendor packages against upstream commits.

Residual risks and operational caveats:

• Vendor lag: embedded, OEM, or appliance kernels and long‑tail builds may not receive the backport promptly. Track vendors and escalate where necessary for appliances and storage nodes.
• Local attack vector: while the vulnerability is local, many real deployments (CI, multi‑tenant hosts, virtualization platforms) effectively expose local attack surfaces to untrusted workloads; these environments require higher prioritization.
• Testing is necessary: kernel upgrades require careful staging — even minimal fixes can interact with vendor drivers or storage stacks in subtle ways. Use pilot rings and have rollback plans.

---

Practical recommendations for WindowsForum readers who manage Linux hosts​

• Inventory and prioritize: identify hosts that run md, clustermd, device‑mapper, or automated image ingestion. Prioritize multi‑tenant, virtualization and storage hosts.
• Patch quickly but safely: apply the vendor kernel update that includes the upstream stable commit; use staged rollouts and reboots during maintenance windows.
• Harden operations: restrict who can run mdadm or manipulate device‑mapper objects; remove unnecessary exposure of block device control to untrusted containers.
• Validate fixes: after patching, rerun any failing tests (including mdadm/clustermd test cases if you run them) and monitor kernel logs for unexpected md/writing behavior.
• Track vendor advisories: rely on your distribution or appliance vendor to map upstream commit IDs into package versions — don’t assume upstream means immediate coverage on your vendor kernel.

---

Conclusion​

CVE‑2025‑22124 is a compact but consequential bug: a wrong bitmap_limit computation in clustermd’s md/md‑bitmap write path that could prevent superblock writes for a node’s first 4 KB page and cause deterministic hangs during resize/grow operations. The fix is small, upstream, and appropriate — an index correction using modulo arithmetic — and distributions have mapped the remediation into kernel updates. Because the flaw impacts availability and is reproducible under specific test sequences, organizations that run MD arrays, clustermd, or host multi‑tenant image processing workloads should schedule prompt kernel updates and take immediate mitigations for vulnerable systems until patched. Cross‑checked public records and upstream stable commits confirm the root cause and the minimal remedial change; operators should validate vendor package changelogs against the upstream fixes before deploying at scale.

---

(Technical note: the public CVE entries and vendor advisories referenced above include the small upstream stable commit references; consult your distribution’s security tracker to map those commits to the exact kernel package for your release before applying any production updates.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center