ZDF
Sign inSign up

Vulnerabilities

Vulnerability · CVE-2026-46050

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…

Published May 27, 2026 · catalog updated Oct 15, 2026 · linux kernel

Check if you run it

No confirmed exploitation is on record for CVE-2026-46050. EPSS is 0.13%. Act only if a listed version of linux kernel is installed.

Gaps on this record

  • No vendor fix or required action is stored. Compare the linked advisory before you change production.
Severity
Medium5.5
Known exploitation
Not in CISA/VulnCheck KEV
EPSS
0.13%
Remediation
Advisory link
Affected products
cpe linux/linux kernel

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 [ ] raise_barrier+0xce/0x1c0 [ ] raid10_sync_request+0x1ca/0x1ed0 [ ] md_do_sync+0x779/0x1110 [ ] md_thread+0x90/0x160 [ ] kthread+0xbe/0xf0 [ ] ret_from_fork+0x34/0x50 [ ] ret_from_fork_asm+0x1a/0x30 kworker/u1040:2+flush-253:4 [ ] wait_barrier+0x1de/0x220 [ ] regular_request_wait+0x30/0x180 [ ] raid10_make_request+0x261/0x1000 [ ] md_handle_request+0x13b/0x230 [ ] __submit_bio+0x107/0x1f0 [ ] submit_bio_noacct_nocheck+0x16f/0x390 [ ] ext4_io_submit+0x24/0x40 [ ] ext4_do_writepages+0x254/0xc80 [ ] ext4_writepages+0x84/0x120 [ ] do_writepages+0x7a/0x260 [ ] __writeback_single_inode+0x3d/0x30

Are you affected?

Enter the version you run. The result uses only the ranges stored on this record.

The check returns affected, not affected, or incomplete. It does not guess a version that is missing from the record.

  • cpe linux/linux kernel6.16

How to fix CVE-2026-46050

What to do

Three questions, each answered from this record only. Confirm the vendor advisory before you patch.

Should you patch?

No confirmed exploitation is on record for CVE-2026-46050. EPSS is 0.13%. Act only if a listed version of linux kernel is installed.

Which versions are affected?

Compare what you have installed with linux/linux kernel 6.16. Compare the installed version with the linked vendor advisory before you change production.

What should an analyst verify?

CWE-667. EPSS 0.13%. There is no CISA KEV listing. No Exploit-DB or Metasploit reference is linked. Use the source links for the original advisory.

Code

The project this record applies to. Exploit listings stay in References.

Timeline

Detection, updates, and resolution for this record.

  1. May 27, 2026 · NIST NVD

    Detected

    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 a

  2. Oct 15, 2026 · NIST NVD

    Updated

    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 a

Sources

  • CVE.orgVulnerability recordCVE-2026-46050

    Official CVE identifier

    cve.org
  • FIRST EPSSExploitation probabilityCVE-2026-46050

    30-day exploitation probability 0.1%

    first.org
  • NIST NVDVulnerability recordCVE-2026-46050

    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

    nvd.nist.gov

References

Freshness

Last verified in this catalog Oct 18, 2026. Significant claims (KEV, EPSS, CVSS, affected ranges) come from the source rows above — open the original publisher for the authoritative advisory.