<?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>Tue, 29 Sep 2026 04:43:51 +0000</lastBuildDate>
    <item>
      <title>CVE-2024-43855 — md: fix deadlock between mddev_suspend and flush bio</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2024-43855</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: fix deadlock between mddev_suspend and flush bio&lt;/p&gt;
&lt;p&gt;Deadlock occurs when mddev is being suspended while some flush bio is in
progress. It is a complex issue.&lt;/p&gt;
&lt;p&gt;T1. the first flush is at the ending stage, it clears &amp;#39;mddev-&amp;gt;flush_bio&amp;#39;
    and tries to submit data, but is blocked because mddev is suspended
    by T4.
T2. the second flush sets &amp;#39;mddev-&amp;gt;flush_bio&amp;#39;, and attempts to queue
    md_submit_flush_data(), which is already running (T1) and won&amp;#39;t
    execute again if on the same CPU as T1.
T3. the third flush inc active_io and tries to flush, but is blocked because
    &amp;#39;mddev-&amp;gt;flush_bio&amp;#39; is not NULL (set by T2).
T4. mddev_suspend() is called and waits for active_io dec to 0 which is inc
    by T3.&lt;/p&gt;
&lt;p&gt;T1		T2		T3		T4
  (flush 1)	(flush 2)	(third 3)	(suspend)
  md_submit_flush_data
   mddev-&amp;gt;flush_bio = NULL;
   .
   .	 	md_flush_request
   .	  	 mddev-&amp;gt;flush_bio = bio
   .	  	 queue submit_flushes
   .		 .
   .		 .		md_handle_request
   .		 .		 active_io + 1
   .		 .		 md_flush_request
   .		 .		  wait !mddev-&amp;gt;flush_bio
   .		 .
   .		 .				mddev_suspend
   .		 .				 wait !active_io
   .		 .
   .		 submit_flushes
   .		 queue_work md_submit_flush_data
   .		 //md_submit_flush_data is already running (T1)
   .
   md_handle_request
    wait resume&lt;/p&gt;
&lt;p&gt;The root issue is non-atomic inc/dec of active_io during flush process.
active_io is dec before md_submit_flush_data is queued, and inc soon
after md_submit_flush_…&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: fix deadlock between mddev_suspend and flush bio&lt;/p&gt;
&lt;p&gt;Deadlock occurs when mddev is being suspended while some flush bio is in
progress. It is a complex issue.&lt;/p&gt;
&lt;p&gt;T1. the first flush is at the ending stage, it clears &amp;#39;mddev-&amp;gt;flush_bio&amp;#39;
    and tries to submit data, but is blocked because mddev is suspended
    by T4.
T2. the second flush sets &amp;#39;mddev-&amp;gt;flush_bio&amp;#39;, and attempts to queue
    md_submit_flush_data(), which is already running (T1) and won&amp;#39;t
    execute again if on the same CPU as T1.
T3. the third flush inc active_io and tries to flush, but is blocked because
    &amp;#39;mddev-&amp;gt;flush_bio&amp;#39; is not NULL (set by T2).
T4. mddev_suspend() is called and waits for active_io dec to 0 which is inc
    by T3.&lt;/p&gt;
&lt;p&gt;T1		T2		T3		T4
  (flush 1)	(flush 2)	(third 3)	(suspend)
  md_submit_flush_data
   mddev-&amp;gt;flush_bio = NULL;
   .
   .	 	md_flush_request
   .	  	 mddev-&amp;gt;flush_bio = bio
   .	  	 queue submit_flushes
   .		 .
   .		 .		md_handle_request
   .		 .		 active_io + 1
   .		 .		 md_flush_request
   .		 .		  wait !mddev-&amp;gt;flush_bio
   .		 .
   .		 .				mddev_suspend
   .		 .				 wait !active_io
   .		 .
   .		 submit_flushes
   .		 queue_work md_submit_flush_data
   .		 //md_submit_flush_data is already running (T1)
   .
   md_handle_request
    wait resume&lt;/p&gt;
&lt;p&gt;The root issue is non-atomic inc/dec of active_io during flush process.
active_io is dec before md_submit_flush_data is queued, and inc soon
after md_submit_flush_…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2024-43855</guid>
    </item>
  </channel>
</rss>
