CVE-2026-46050

What it actually does

This is a local denial-of-service flaw in the Linux kernel md RAID10 driver. During a RAID10 array check operation, normal I/O requests wait behind a synchronization barrier and increment the internal pending-request counter. NOWAIT I/O requests return immediately instead of waiting, but an error-handling path incorrectly decrements the pending counter even though it was never incremented. This can underflow the md/raid10 nr_pending counter, leaving the md resync thread permanently waiting for the counter to reach zero and causing subsequent RAID10 I/O to block. The impact is availability loss for workloads using affected md RAID10 arrays; it does not provide confidentiality, integrity, or code-execution impact.

Why it matters to the business

Systems that rely on Linux software RAID10 can experience storage stalls or service outages if the vulnerable condition is triggered. Applications backed by the affected array may hang, fail health checks, lose availability, or require a reboot or storage stack recovery to restore normal operation. Because exploitation requires local access and a specific combination of RAID10 check activity plus NOWAIT I/O, broad internet-scale exploitation is unlikely; however, multi-user systems, shared compute platforms, and environments running applications that use io_uring or NOWAIT I/O are more exposed. EPSS is very low and the issue is not known to be in CISA KEV or ransomware campaigns, but the operational impact can still be severe where affected RAID10 arrays support critical services.

How an attack unfolds

An attacker first needs local ability to run code or submit I/O against a filesystem or block device backed by an affected Linux md RAID10 array. The attacker then waits for or induces a RAID10 check operation, such as a scheduled consistency check. While the check has raised the RAID10 barrier, the attacker repeatedly submits NOWAIT I/O requests to the same array. In the vulnerable kernel path, those NOWAIT requests fail fast but still trigger cleanup logic that decrements the RAID10 pending-request counter without a matching increment. After enough occurrences, the counter underflows. The md resync thread then waits indefinitely for the counter to return to zero, while other I/O threads become stuck in the RAID10 barrier wait path. The result is a local storage denial of service, typically observed as hung tasks, blocked writeback, stuck md resync activity, and application I/O hangs.

How to fix it

Apply a Linux kernel update that includes the md/raid10 fix for the NOWAIT request barrier accounting bug. If your distribution publishes per-release advisories, use the vendor-supported kernel package rather than attempting to backport manually. No fixed package versions were provided in the input, so track the relevant distribution advisory for the exact kernel build containing the md/raid10 deadlock fix. Until patched, reduce exposure by avoiding or rescheduling RAID10 check operations during periods where applications perform NOWAIT I/O, limiting local shell or code-execution access on systems using md RAID10, disabling or reconfiguring application features that generate NOWAIT I/O where feasible, and closely monitoring scheduled md checks. If a system enters the deadlocked state, recovery may require stopping affected workloads, attempting controlled md maintenance actions where safe, or rebooting the host; prioritize data safety and follow storage vendor/distribution guidance before forcing array operations.

How to confirm the fix worked

Confirm whether hosts use Linux md RAID10 by checking /proc/mdstat, mdadm --detail, and /sys/block/md*/md/level for raid10 arrays. Confirm the running kernel has been updated to a vendor release containing the fix by comparing uname -a and package manager output against the distribution security advisory. Validate that md check operations complete normally by observing /proc/mdstat and /sys/block/md*/md/sync_action during and after a check. In a non-production test environment only, reproduce the risk condition by running a RAID10 check while generating NOWAIT I/O and verifying that the patched kernel does not produce hung tasks, blocked md*_resync threads, or persistent I/O stalls. Also review kernel logs after patching to ensure there are no recurring messages indicating blocked tasks in raise_barrier, wait_barrier, raid10_make_request, or md_do_sync.

Typical attack path

1. Gain local access to a Linux system using md RAID10 storage, or compromise an application account capable of issuing file or block I/O backed by the affected array.
2. Identify or wait for a RAID10 check operation, commonly visible through /proc/mdstat or /sys/block/md*/md/sync_action.
3. Generate repeated NOWAIT I/O to files or block devices on the affected RAID10 array, for example through application code using nonblocking I/O interfaces such as io_uring or RWF_NOWAIT.
4. Trigger the mismatched accounting path where NOWAIT requests return without incrementing nr_pending but still cause nr_pending to be decremented during cleanup.
5. Cause nr_pending to underflow, leaving the md resync/check thread stuck waiting for pending requests to drain.
6. Sustain a denial-of-service condition as normal filesystem and block I/O queues behind the RAID10 barrier and dependent applications hang or fail.

How to detect it

Look for evidence of a local storage denial-of-service rather than remote compromise. Primary sources are kernel logs, journald, dmesg, /var/log/kern.log, /var/log/messages, sysrq task dumps, crash dumps, and monitoring telemetry for disk latency and blocked tasks. Indicators include md RAID10 check operations that never complete, md*_resync threads stuck in raise_barrier or md_do_sync, worker or application threads stuck in wait_barrier or raid10_make_request, and kernel hung-task warnings during or shortly after an md check. Use /proc/mdstat history or monitoring data to correlate the start of an array check with sudden I/O stalls. In crash dumps, inspect the r10conf structure for barrier set and nr_pending showing a negative value, which is highly suggestive of this bug. Also review local process accounting, audit logs, and application logs for users or services generating high rates of NOWAIT I/O around the onset time. There are no known public threat actors or ransomware campaigns associated with this issue, and successful exploitation may leave no unique file, network, or registry artifact beyond kernel/storage symptoms.

• blocked for more than 120 seconds
• md1_resync
• md*_resync
• raise_barrier
• wait_barrier
• raid10_sync_request
• raid10_make_request
• md_do_sync
• md_thread
• regular_request_wait
• md_handle_request
• nr_pending
• counter = -
• barrier = 1
• /proc/mdstat
• /sys/block/md*/md/sync_action
• check
• kworker
• flush-
• ext4_writepages
• __writeback_single_inode
• INFO: task
• hung task

What your security team should do

• Inventory Linux systems using md RAID10 and prioritize those supporting critical services, shared compute, databases, virtualization, or container platforms.
• Patch affected systems with the vendor-supported kernel update containing the md/raid10 NOWAIT deadlock fix, then reboot or live-patch as required by the distribution.
• Temporarily avoid running RAID10 check operations during peak workload periods on unpatched systems, especially where applications use io_uring, RWF_NOWAIT, or other NOWAIT I/O paths.
• Restrict local code execution and shell access on unpatched RAID10 systems; this flaw requires local interaction with the affected storage path.
• Add monitoring for hung task kernel messages involving md*_resync, raise_barrier, wait_barrier, raid10_make_request, and md_do_sync.
• Review scheduled mdadm check jobs and operational runbooks so storage teams can quickly identify and respond to an md RAID10 deadlock.
• If symptoms are observed, preserve kernel logs and, where possible, crash dumps or sysrq task traces before rebooting, to support root-cause confirmation.