Skip to main content

Linux Kernel EUVDEUVD-2026-32432

| CVE-2026-46050 MEDIUM
Improper Locking (CWE-667)
2026-05-27 416baaa9-dc9f-4396-8d5f-8c081fb06d67 GHSA-7v6r-2w32-rrq7
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
vuln.today AI
5.5 MEDIUM

Local access with low privilege required to trigger concurrent NOWAIT IO and check operation; no confidentiality or integrity impact, only availability via permanent deadlock.

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
MEDIUM
qualitative
Red Hat
5.5 MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jun 16, 2026 - 15:11 vuln.today
CVSS changed
Jun 16, 2026 - 15:07 NVD
5.5 (MEDIUM)
Patch available
May 27, 2026 - 19:46 EUVD
CVE Published
May 27, 2026 - 14:17 nvd
MEDIUM 5.5
CVE Published
May 27, 2026 - 14:17 nvd
UNKNOWN (no severity yet)

DescriptionNVD

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

AnalysisAI

Deadlock in the Linux kernel md/raid10 subsystem causes a permanent denial-of-service when NOWAIT IO requests coincide with an array check (resync) operation. The md resync thread becomes permanently stuck because the nr_pending atomic counter underflows to a large negative value, preventing it from ever reaching the zero threshold needed to proceed. Systems running RAID-10 arrays where applications use O_NOWAIT IO (e.g., filesystem writeback paths via ext4) are affected. No public exploit code exists and EPSS is 0.02%, indicating low exploitation probability, but the bug is deterministically reproducible by any local user with IO access to the affected array.

Technical ContextAI

The md/raid10 subsystem implements RAID-10 (mirrored striping) in the Linux kernel via a barrier/pending accounting mechanism. When a check or resync operation begins, raise_barrier() increments a barrier counter and the resync thread then waits for nr_pending (atomic counter tracking in-flight requests) to reach zero before proceeding. Normal requests call wait_barrier(), which increments nr_pending and blocks if a barrier is raised; when they complete, allow_barrier() decrements nr_pending. NOWAIT requests (O_NOWAIT / RWF_NOWAIT flag, used by filesystems like ext4 during writeback) intentionally skip wait_barrier() and return EAGAIN immediately - critically, without ever incrementing nr_pending. Upstream commit 43806c3d5b9b ('raid10: cleanup memleak at raid10_make_request') added a raid_end_bio_io() call to handle the NOWAIT early-exit path to fix a memory leak, but raid_end_bio_io() chains into allow_barrier(), which unconditionally performs atomic_dec_and_test(&conf->nr_pending). Because the NOWAIT path never incremented nr_pending, each such call causes the counter to underflow (observed at -41 in crash data). The resync thread then spins indefinitely in raise_barrier() waiting for the counter to equal zero, which it never will. CWE-667 (Improper Locking) applies: the decrement and increment are unbalanced across code paths, violating the invariant that allow_barrier() is only called after a corresponding wait_barrier() increment.

RemediationAI

Upgrade to a patched kernel version: 6.6.140, 6.12.86, 7.0.4, 6.18.27, or 7.1-rc1 per EUVD patch data. Upstream fix commits are available at 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, and https://git.kernel.org/stable/c/cac2106bb9a2180b288079b49ed626414fb5bc45. If patching is not immediately possible, a targeted workaround is to avoid running md array check operations while workloads using O_NOWAIT or RWF_NOWAIT IO (notably ext4 writeback via kworker flush threads) are active against the same RAID-10 device. This can be operationally achieved by scheduling check operations during maintenance windows with IO-generating workloads quiesced or by temporarily disabling periodic md checks via 'echo none > /sys/block/md1/md/sync_action'. This workaround prevents the trigger condition but leaves the underlying kernel bug in place and does not protect against concurrent NOWAIT IO from unpredictable workloads.

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
openSUSE Tumbleweed Fixed
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected

Share

EUVD-2026-32432 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy