CVE-2026-46050 - Vulnerability Details

- md/raid10: fix deadlock with check operation and nowait requests

Description

In the Linux kernel, the following vulnerability has been resolved:

md/raid10: fix deadlock with check operation and nowait requests

When an array check is running it will raise the barrier at which point
normal requests will become blocked and increment the nr_pending value to
signal there is work pending inside of wait_barrier(). NOWAIT requests
do not block and so will return immediately with an error, and additionally
do not increment nr_pending in wait_barrier(). Upstream change commit
43806c3d5b9b ("raid10: cleanup memleak at raid10_make_request") added a
call to raid_end_bio_io() to fix a memory leak when NOWAIT requests hit
this condition. raid_end_bio_io() eventually calls allow_barrier() and
it will unconditionally do an atomic_dec_and_test(&conf->nr_pending) even
though the corresponding increment on nr_pending didn't happen in the
NOWAIT case.

This can be easily seen by starting a check operation while an application
is doing nowait IO on the same array. This results in a deadlocked state
due to nr_pending value underflowing and so the md resync thread gets stuck
waiting for nr_pending to == 0.

Output of r10conf state of the array when we hit this condition:

crash> struct r10conf
barrier = 1,
nr_pending = {
counter = -41
},
nr_waiting = 15,
nr_queued = 0,

Example of md_sync thread stuck waiting on raise_barrier() and other
requests stuck in wait_barrier():

md1_resync
[<0>] raise_barrier+0xce/0x1c0
[<0>] raid10_sync_request+0x1ca/0x1ed0
[<0>] md_do_sync+0x779/0x1110
[<0>] md_thread+0x90/0x160
[<0>] kthread+0xbe/0xf0
[<0>] ret_from_fork+0x34/0x50
[<0>] ret_from_fork_asm+0x1a/0x30

kworker/u1040:2+flush-253:4
[<0>] wait_barrier+0x1de/0x220
[<0>] regular_request_wait+0x30/0x180
[<0>] raid10_make_request+0x261/0x1000
[<0>] md_handle_request+0x13b/0x230
[<0>] __submit_bio+0x107/0x1f0
[<0>] submit_bio_noacct_nocheck+0x16f/0x390
[<0>] ext4_io_submit+0x24/0x40
[<0>] ext4_do_writepages+0x254/0xc80
[<0>] ext4_writepages+0x84/0x120
[<0>] do_writepages+0x7a/0x260
[<0>] __writeback_single_inode+0x3d/0x300
[<0>] writeback_sb_inodes+0x1dd/0x470
[<0>] __writeback_inodes_wb+0x4c/0xe0
[<0>] wb_writeback+0x18b/0x2d0
[<0>] wb_workfn+0x2a1/0x400
[<0>] process_one_work+0x149/0x330
[<0>] worker_thread+0x2d2/0x410
[<0>] kthread+0xbe/0xf0
[<0>] ret_from_fork+0x34/0x50
[<0>] ret_from_fork_asm+0x1a/0x30

Published: 2026-05-27

Score: 5.5 Medium

EPSS: n/a

KEV: No

Impact:

Action:

Analysis

Impact

A counter underflow occurs in the Linux RAID10 driver when a check operation runs concurrently with NOWAIT I/O requests. This causes the pending counter to drop below zero, preventing the resync thread from exiting its wait state. As a result, I/O to the affected array is blocked, effectively creating a denial-of-service condition for the RAID10 volume.

Affected Systems

All unpatched Linux kernels implementing RAID10 (including the legacy implementation) on arrays that enable NOWAIT operations and schedule consistency checks are affected. The fix is in commit 43806c3d5b9b, so any distribution kernel that has not merged this patch remains vulnerable.

Risk and Exploitability

EPSS has no data and the flaw is not listed in the CISA KEV catalog, indicating no public exploits yet. The vulnerability requires a specific sequence of operations that is unlikely to occur accidentally, but an administrator or application that schedules checks during periods of high-speed NOWAIT I/O could trigger it. The risk is moderate, primarily for environments that run RAID10 arrays with frequent consistency checks or perform large numbers of NOWAIT I/O operations. The CVSS score of 5.5 indicates moderate severity.

Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).

Vendor Product Default status Versions

Linux

unaffected

Version	Status	Constraints
`8fc3d7b23d139e3cbc944c15d99b3cdbed797d2d`	affected	< 965d6162dd88cc7cc193cf7f5bfc132d8bbf0523
`2941155d9a5ae098b480d551f3a5f8605d4f9af5`	affected	< 42fe37c90184cd1568838b84b488934c3671c963
`43806c3d5b9bb7d74ba4e33a6a8a41ac988bde24`	affected	< cac2106bb9a2180b288079b49ed626414fb5bc45
`43806c3d5b9bb7d74ba4e33a6a8a41ac988bde24`	affected	< 1cdff2937c618f81058422bbdc4974a3e7ec9379
`43806c3d5b9bb7d74ba4e33a6a8a41ac988bde24`	affected	< 7d96f3120a7fb7210d21b520c5b6f495da6ba436
`10c6021a609deb95f23f0cc2f89aa9d4bffb14c7`	affected	—
`9af149ca9d0dab6e59e813519d309eff62499864`	affected	—
`ed7bcd9f617e4107ac0813c516e72e6b8f6029bd`	affected	—
`6.6.99`	affected	< 6.6.140
`6.12.39`	affected	< 6.12.86
`5.15.189`	affected	< 5.16
`6.1.146`	affected	< 6.2
`6.15.7`	affected	< 6.16

Linux

affected

Version	Status	Constraints
`6.16`	affected	—
`0`	unaffected	< 6.16
`6.6.140`	unaffected	≤ 6.6.*
`6.12.86`	unaffected	≤ 6.12.*
`6.18.27`	unaffected	≤ 6.18.*
`7.0.4`	unaffected	≤ 7.0.*
`7.1-rc1`	unaffected	≤ *

No data.

Vendor Product Confidence Versions

Linux

Linux Kernel

99%

Version	Status	Scheme	Platform
`[8fc3d7b23d139e3cbc944c15d99b3cdbed797d2d,965d6162dd88cc7cc193cf7f5bfc132d8bbf0523)`	affected	code_commit	—
`[2941155d9a5ae098b480d551f3a5f8605d4f9af5,42fe37c90184cd1568838b84b488934c3671c963)`	affected	code_commit	—
`[43806c3d5b9bb7d74ba4e33a6a8a41ac988bde24,cac2106bb9a2180b288079b49ed626414fb5bc45)`	affected	code_commit	—
`[43806c3d5b9bb7d74ba4e33a6a8a41ac988bde24,1cdff2937c618f81058422bbdc4974a3e7ec9379)`	affected	code_commit	—
`[43806c3d5b9bb7d74ba4e33a6a8a41ac988bde24,7d96f3120a7fb7210d21b520c5b6f495da6ba436)`	affected	code_commit	—
`10c6021a609deb95f23f0cc2f89aa9d4bffb14c7`	affected	code_commit	—
`9af149ca9d0dab6e59e813519d309eff62499864`	affected	code_commit	—
`ed7bcd9f617e4107ac0813c516e72e6b8f6029bd`	affected	code_commit	—
`[6.6.99,6.6.140)`	affected	semver	—
`[6.12.39,6.12.86)`	affected	semver	—
`[5.15.189,5.16)`	affected	semver	—
`[6.1.146,6.2)`	affected	semver	—
`[6.15.7,6.16)`	affected	semver	—

Linux

Linux Kernel

99%

Version	Status	Scheme	Platform
`6.16`	affected	semver	—
`[0,6.16)`	unaffected	semver	—
`[6.6.140,6.7.0)`	unaffected	semver	—
`[6.12.86,6.13.0)`	unaffected	semver	—
`[6.18.27,6.19.0)`	unaffected	semver	—
`[7.0.4,7.1.0)`	unaffected	semver	—
`[7.1-rc1,*]`	unaffected	generic	—

Found an issue or want to improve our Enrichment? You can suggest it directly by opening an issue on our dedicated GitHub repository .

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

Upgrade the Linux kernel to a release that includes commit 43806c3d5b9b, which fixes the counter underflow and deadlock.
Schedule RAID10 consistency checks during periods of low I/O or suspend NOWAIT operations while a check is in progress.
Monitor kernel logs for messages such as "raise_barrier" hang or negative values in the nr_pending counter as an early indicator.
If immediate patching is not possible, disable NOWAIT I/O features on affected arrays until the kernel update can be applied.

Generated by OpenCVE AI on May 28, 2026 at 04:29 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

No CVSS v4.0

Attack Vector Local

Attack Complexity Low

Privileges Required Low

Scope Unchanged

Confidentiality Impact None

Integrity Impact None

Availability Impact High

User Interaction None

No CVSS v3.0

No CVSS v2

This CVE is not in the KEV list.

No EPSS score available.

Key SSVC decision points have not yet been added.

References

Link	Providers
https://git.kernel.org/stable/c/1cdff2937c618f81058422bbdc4974a3e7ec9379
https://git.kernel.org/stable/c/42fe37c90184cd1568838b84b488934c3671c963
https://git.kernel.org/stable/c/7d96f3120a7fb7210d21b520c5b6f495da6ba436
https://git.kernel.org/stable/c/965d6162dd88cc7cc193cf7f5bfc132d8bbf0523
https://git.kernel.org/stable/c/cac2106bb9a2180b288079b49ed626414fb5bc45
https://lore.kernel.org/linux-cve-announce/2026052753-CVE-2026-46050-8377@gregkh/T
https://nvd.nist.gov/vuln/detail/CVE-2026-46050
https://www.cve.org/CVERecord?id=CVE-2026-46050

History

Thu, 28 May 2026 03:45:00 +0000

Type	Values Removed	Values Added
Weaknesses	CWE-471

Thu, 28 May 2026 00:15:00 +0000

Type	Values Removed	Values Added
References		https://lore.kernel.org/linux-cve-announce/2026052753-CVE-2026-46050-8377@gregkh/T https://nvd.nist.gov/vuln/detail/CVE-2026-46050 https://www.cve.org/CVERecord?id=CVE-2026-46050
Metrics	threat_severity `None`	cvssV3_1 `{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}` threat_severity `Moderate`

Wed, 27 May 2026 20:45:00 +0000

Type	Values Removed	Values Added
Weaknesses		CWE-191 CWE-471

Wed, 27 May 2026 14:15:00 +0000

Type	Values Removed	Values Added
Description		In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix deadlock with check operation and nowait requests When an array check is running it will raise the barrier at which point normal requests will become blocked and increment the nr_pending value to signal there is work pending inside of wait_barrier(). NOWAIT requests do not block and so will return immediately with an error, and additionally do not increment nr_pending in wait_barrier(). Upstream change commit 43806c3d5b9b ("raid10: cleanup memleak at raid10_make_request") added a call to raid_end_bio_io() to fix a memory leak when NOWAIT requests hit this condition. raid_end_bio_io() eventually calls allow_barrier() and it will unconditionally do an atomic_dec_and_test(&conf->nr_pending) even though the corresponding increment on nr_pending didn't happen in the NOWAIT case. This can be easily seen by starting a check operation while an application is doing nowait IO on the same array. This results in a deadlocked state due to nr_pending value underflowing and so the md resync thread gets stuck waiting for nr_pending to == 0. Output of r10conf state of the array when we hit this condition: crash> struct r10conf barrier = 1, nr_pending = { counter = -41 }, nr_waiting = 15, nr_queued = 0, Example of md_sync thread stuck waiting on raise_barrier() and other requests stuck in wait_barrier(): md1_resync [<0>] raise_barrier+0xce/0x1c0 [<0>] raid10_sync_request+0x1ca/0x1ed0 [<0>] md_do_sync+0x779/0x1110 [<0>] md_thread+0x90/0x160 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30 kworker/u1040:2+flush-253:4 [<0>] wait_barrier+0x1de/0x220 [<0>] regular_request_wait+0x30/0x180 [<0>] raid10_make_request+0x261/0x1000 [<0>] md_handle_request+0x13b/0x230 [<0>] __submit_bio+0x107/0x1f0 [<0>] submit_bio_noacct_nocheck+0x16f/0x390 [<0>] ext4_io_submit+0x24/0x40 [<0>] ext4_do_writepages+0x254/0xc80 [<0>] ext4_writepages+0x84/0x120 [<0>] do_writepages+0x7a/0x260 [<0>] __writeback_single_inode+0x3d/0x300 [<0>] writeback_sb_inodes+0x1dd/0x470 [<0>] __writeback_inodes_wb+0x4c/0xe0 [<0>] wb_writeback+0x18b/0x2d0 [<0>] wb_workfn+0x2a1/0x400 [<0>] process_one_work+0x149/0x330 [<0>] worker_thread+0x2d2/0x410 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30
Title		md/raid10: fix deadlock with check operation and nowait requests
First Time appeared		Linux Linux linux Kernel
CPEs		cpe:2.3:o:linux:linux_kernel::::::::
Vendors & Products		Linux Linux linux Kernel
References		https://git.kernel.org/stable/c/1cdff2937c618f81058422bbdc4974a3e7ec9379 https://git.kernel.org/stable/c/42fe37c90184cd1568838b84b488934c3671c963 https://git.kernel.org/stable/c/7d96f3120a7fb7210d21b520c5b6f495da6ba436 https://git.kernel.org/stable/c/965d6162dd88cc7cc193cf7f5bfc132d8bbf0523 https://git.kernel.org/stable/c/cac2106bb9a2180b288079b49ed626414fb5bc45

Subscriptions

Linux Linux Kernel

MITRE

Status: PUBLISHED

Assigner: Linux

Published: 2026-05-27T12:57:06.732Z

Updated: 2026-05-27T12:57:06.732Z

Reserved: 2026-05-13T15:03:33.094Z

Link: CVE-2026-46050

Vulnrichment

No data.

NVD

Status : Awaiting Analysis

Published: 2026-05-27T14:17:24.547

Modified: 2026-05-27T14:48:03.013

Link: CVE-2026-46050

Redhat

Severity : Moderate

Publid Date: 2026-05-27T00:00:00Z

Links: CVE-2026-46050 - Bugzilla

OpenCVE Enrichment

Updated: 2026-05-28T04:30:06Z

Weaknesses

CWE-191

Impact

Affected Systems

Risk and Exploitability

Tracking

Attack Vector Local

Attack Complexity Low

Privileges Required Low

Scope Unchanged

Confidentiality Impact None

Integrity Impact None

Availability Impact High

User Interaction None

Subscriptions

JSON object

JSON object

JSON object

JSON object

JSON object