<?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 20:48:38 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-43065 — ext4: always drain queued discard work in ext4_mb_release()</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-43065</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;ext4: always drain queued discard work in ext4_mb_release()&lt;/p&gt;
&lt;p&gt;While reviewing recent ext4 patch[1], Sashiko raised the following
concern[2]:&lt;/p&gt;
&lt;p&gt;&amp;gt; If the filesystem is initially mounted with the discard option,
&amp;gt; deleting files will populate sbi-&amp;gt;s_discard_list and queue
&amp;gt; s_discard_work. If it is then remounted with nodiscard, the
&amp;gt; EXT4_MOUNT_DISCARD flag is cleared, but the pending s_discard_work is
&amp;gt; neither cancelled nor flushed.&lt;/p&gt;
&lt;p&gt;[1] https://lore.kernel.org/r/20260319094545.19291-1-qiang.zhang@linux.dev/
[2] https://sashiko.dev/#/patchset/20260319094545.19291-1-qiang.zhang%40linux.dev&lt;/p&gt;
&lt;p&gt;The concern was valid, but it had nothing to do with the patch[1].
One of the problems with Sashiko in its current (early) form is that
it will detect pre-existing issues and report it as a problem with the
patch that it is reviewing.&lt;/p&gt;
&lt;p&gt;In practice, it would be hard to hit deliberately (unless you are a
malicious syzkaller fuzzer), since it would involve mounting the file
system with -o discard, and then deleting a large number of files,
remounting the file system with -o nodiscard, and then immediately
unmounting the file system before the queued discard work has a change
to drain on its own.&lt;/p&gt;
&lt;p&gt;Fix it because it&amp;#39;s a real bug, and to avoid Sashiko from raising this
concern when analyzing future patches to mballoc.c.&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;ext4: always drain queued discard work in ext4_mb_release()&lt;/p&gt;
&lt;p&gt;While reviewing recent ext4 patch[1], Sashiko raised the following
concern[2]:&lt;/p&gt;
&lt;p&gt;&amp;gt; If the filesystem is initially mounted with the discard option,
&amp;gt; deleting files will populate sbi-&amp;gt;s_discard_list and queue
&amp;gt; s_discard_work. If it is then remounted with nodiscard, the
&amp;gt; EXT4_MOUNT_DISCARD flag is cleared, but the pending s_discard_work is
&amp;gt; neither cancelled nor flushed.&lt;/p&gt;
&lt;p&gt;[1] https://lore.kernel.org/r/20260319094545.19291-1-qiang.zhang@linux.dev/
[2] https://sashiko.dev/#/patchset/20260319094545.19291-1-qiang.zhang%40linux.dev&lt;/p&gt;
&lt;p&gt;The concern was valid, but it had nothing to do with the patch[1].
One of the problems with Sashiko in its current (early) form is that
it will detect pre-existing issues and report it as a problem with the
patch that it is reviewing.&lt;/p&gt;
&lt;p&gt;In practice, it would be hard to hit deliberately (unless you are a
malicious syzkaller fuzzer), since it would involve mounting the file
system with -o discard, and then deleting a large number of files,
remounting the file system with -o nodiscard, and then immediately
unmounting the file system before the queued discard work has a change
to drain on its own.&lt;/p&gt;
&lt;p&gt;Fix it because it&amp;#39;s a real bug, and to avoid Sashiko from raising this
concern when analyzing future patches to mballoc.c.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-43065</guid>
    </item>
  </channel>
</rss>
