CVE-2026-53125

What it actually does

This is a Linux kernel race/lifetime bug in the md (multiple devices / software RAID) subsystem's sysfs handling for `/sys/block/md*/md/array_state`. When `clear` is written to `array_state`, the kernel temporarily breaks sysfs active protection so the md device can remove itself while servicing the sysfs write. The vulnerable code releases the md device reference before restoring sysfs active protection, allowing the sysfs/kobject reference to become the last reference and triggering kobject teardown from within the same sysfs write path. That can recurse into kernfs removal while the current sysfs node is still active, causing recursive locking warnings and potential kernel instability or denial of service. Exploitation requires local ability to manipulate md arrays through sysfs, typically requiring root or equivalent administrative capability.

Why it matters to the business

Systems using Linux software RAID or md devices may be vulnerable to a local denial-of-service condition if an administrator-level process, compromised privileged account, or malicious local workload can create or clear md arrays. The most likely consequence is host instability, kernel warnings, hung management operations, or disruption to storage availability on affected systems. Because this issue is not listed in CISA KEV, has very low EPSS, and has no known exploit maturity, immediate internet-facing exploitation is unlikely; however, kernel fixes should still be prioritized for systems where local privilege boundaries, shared administrative environments, or storage uptime are important.

How an attack unfolds

An attacker first needs local privileged access sufficient to create or control Linux md arrays and write to md sysfs attributes. They create or identify an md device, configure it into an active state, and then write `clear` to `/sys/block/mdX/md/array_state`. In vulnerable kernels, the md sysfs store path can drop the md device reference before restoring sysfs active protection. If the reference ordering aligns, the current sysfs write can become responsible for releasing the last kobject reference, causing kobject teardown to recurse into kernfs removal while the same sysfs node is still being unwound. The observable result is a kernel recursive locking warning and possible service degradation, storage-management disruption, or host instability. There is no indication from the provided data that this is remotely exploitable or currently used by named threat actors or ransomware campaigns.

How to fix it

Apply a Linux kernel update that includes the md fix for the `array_state=clear` sysfs reference-ordering deadlock. The corrected behavior restores sysfs active protection before releasing the md device reference, ensuring md kobject deletion is deferred until after the sysfs write path returns. If a vendor kernel is used, install the relevant distribution kernel security or stable update rather than attempting to patch the upstream kernel manually. No exact fixed package versions were provided in the input, so remediation should be tracked through the operating system or kernel vendor advisory for this issue. As temporary mitigation, restrict local administrative access, limit container or workload access to host `/sys`, avoid exposing `/sys/block/md*/md/array_state` into containers, and restrict the ability to create or manipulate md devices to trusted storage administrators only.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix for the md `array_state=clear` sysfs deadlock by checking the installed kernel package against the vendor advisory or changelog. Validate that untrusted users and containers cannot write to `/sys/block/md*/md/array_state` and do not have device-management privileges for md arrays. On test systems only, a controlled regression test can create an md array, activate it, write `clear` to its `array_state`, and verify that no recursive locking warning, kernfs drain recursion, kernel warning, or hang appears in `dmesg` or the system journal. Do not run destructive md-array tests on production systems or on arrays containing important data.

Typical attack path

1. Obtain local root, CAP_SYS_ADMIN-like capability, or equivalent permission to manage md devices and write to md sysfs attributes.
2. Create or access an md device such as `/dev/md0`.
3. Configure the md device through sysfs, including metadata, level, member device, size, slot, and active state.
4. Wait for the md array to become active and settle.
5. Write `clear` to `/sys/block/md0/md/array_state` or another md array's `array_state` sysfs file.
6. Trigger the vulnerable reference-ordering path in md sysfs cleanup.
7. Cause kernel recursive-locking warnings and potential denial of service or storage-management instability.

How to detect it

Look for evidence of local privileged writes to md sysfs controls followed by kernel recursive-locking warnings or storage disruption. Primary log sources include `dmesg`, `/var/log/kern.log`, `/var/log/messages`, `journalctl -k`, auditd logs, shell history for privileged users, EDR process telemetry, and file-integrity or command-monitoring records for writes under `/sys/block/md*/md/`. Search for kernel call traces containing `md_attr_store`, `sysfs_unbreak_active_protection`, `kernfs_drain`, `__kernfs_remove`, `kobject_put`, and `kernfs_fop_write_iter`. Also search for command lines that echo or write `clear` into `/sys/block/md*/md/array_state`, especially near the time of kernel warnings, md array removal, unexpected storage alerts, or host instability. Because this issue has no known public exploitation maturity in the provided data, detections should focus on suspicious local misuse or unexpected administrative actions rather than network indicators.

• /sys/block/md0/md/array_state
• /sys/block/md*/md/array_state
• echo clear > /sys/block/md0/md/array_state
• echo clear > /sys/block/md
• array_state=clear
• WARNING: possible recursive locking detected
• kn->active
• sysfs_unbreak_active_protection
• kernfs_drain
• __kernfs_remove
• kernfs_remove_by_name_ns
• sysfs_remove_group
• sysfs_remove_groups
• __kobject_del
• kobject_put
• md_attr_store
• kernfs_fop_write_iter
• do_md_stop
• /dev/md0
• mknod /dev/md0 b 9 0
• echo active > /sys/block/md0/md/array_state

What your security team should do

• Inventory Linux systems that use md/software RAID or expose md sysfs controls.
• Prioritize kernel updates on storage hosts, virtualization hosts, shared compute systems, and environments where local privilege escalation chains or malicious administrators are a concern.
• Verify that containers, build jobs, and untrusted workloads do not receive host `/sys` write access, privileged mode, or unnecessary device-management capabilities.
• Monitor kernel logs for recursive locking warnings involving `md_attr_store`, `sysfs_unbreak_active_protection`, `kernfs_drain`, or `/sys/block/md*/md/array_state`.
• Review recent privileged shell history, audit logs, and process execution telemetry for writes of `clear` to md `array_state` files.
• Treat any unexpected md array clearing or related kernel warning as a potential local misuse event and investigate the initiating user, process, and parent process chain.
• Track vendor kernel advisories and deploy the fixed kernel through normal reboot or live-patching processes where supported.