<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sun, 04 Oct 2026 12:53:57 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-46050 — md/raid10: fix deadlock with check operation and nowait requests</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-46050</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;md/raid10: fix deadlock with check operation and nowait requests&lt;/p&gt;
&lt;p&gt;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 (&amp;#34;raid10: cleanup memleak at raid10_make_request&amp;#34;) 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(&amp;amp;conf-&amp;gt;nr_pending) even
though the corresponding increment on nr_pending didn&amp;#39;t happen in the
NOWAIT case.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Output of r10conf state of the array when we hit this condition:&lt;/p&gt;
&lt;p&gt;crash&amp;gt; struct r10conf
	barrier = 1,
        nr_pending = {
          counter = -41
        },
        nr_waiting = 15,
        nr_queued = 0,&lt;/p&gt;
&lt;p&gt;Example of md_sync thread stuck waiting on raise_barrier() and other
requests stuck in wait_barrier():&lt;/p&gt;
&lt;p&gt;md1_resync
[&amp;lt;0&amp;gt;] raise_barrier+0xce/0x1c0
[&amp;lt;0&amp;gt;] raid10_syn…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;md/raid10: fix deadlock with check operation and nowait requests&lt;/p&gt;
&lt;p&gt;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 (&amp;#34;raid10: cleanup memleak at raid10_make_request&amp;#34;) 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(&amp;amp;conf-&amp;gt;nr_pending) even
though the corresponding increment on nr_pending didn&amp;#39;t happen in the
NOWAIT case.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Output of r10conf state of the array when we hit this condition:&lt;/p&gt;
&lt;p&gt;crash&amp;gt; struct r10conf
	barrier = 1,
        nr_pending = {
          counter = -41
        },
        nr_waiting = 15,
        nr_queued = 0,&lt;/p&gt;
&lt;p&gt;Example of md_sync thread stuck waiting on raise_barrier() and other
requests stuck in wait_barrier():&lt;/p&gt;
&lt;p&gt;md1_resync
[&amp;lt;0&amp;gt;] raise_barrier+0xce/0x1c0
[&amp;lt;0&amp;gt;] raid10_syn…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-46050</guid>
    </item>
  </channel>
</rss>
