<?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>Fri, 02 Oct 2026 19:33:46 +0000</lastBuildDate>
    <item>
      <title>CVE-2024-36001 — netfs: Fix the pre-flush when appending to a file in writethrough mode</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2024-36001</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;netfs: Fix the pre-flush when appending to a file in writethrough mode&lt;/p&gt;
&lt;p&gt;In netfs_perform_write(), when the file is marked NETFS_ICTX_WRITETHROUGH
or O_*SYNC or RWF_*SYNC was specified, write-through caching is performed
on a buffered file.  When setting up for write-through, we flush any
conflicting writes in the region and wait for the write to complete,
failing if there&amp;#39;s a write error to return.&lt;/p&gt;
&lt;p&gt;The issue arises if we&amp;#39;re writing at or above the EOF position because we
skip the flush and - more importantly - the wait.  This becomes a problem
if there&amp;#39;s a partial folio at the end of the file that is being written out
and we want to make a write to it too.  Both the already-running write and
the write we start both want to clear the writeback mark, but whoever is
second causes a warning looking something like:&lt;/p&gt;
&lt;p&gt;------------[ cut here ]------------
    R=00000012: folio 11 is not under writeback
    WARNING: CPU: 34 PID: 654 at fs/netfs/write_collect.c:105
    ...
    CPU: 34 PID: 654 Comm: kworker/u386:27 Tainted: G S ...
    ...
    Workqueue: events_unbound netfs_write_collection_worker
    ...
    RIP: 0010:netfs_writeback_lookup_folio&lt;/p&gt;
&lt;p&gt;Fix this by making the flush-and-wait unconditional.  It will do nothing if
there are no folios in the pagecache and will return quickly if there are
no folios in the region specified.&lt;/p&gt;
&lt;p&gt;Further, move the WBC attachment above the flush call as the flush is going
to at…&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;netfs: Fix the pre-flush when appending to a file in writethrough mode&lt;/p&gt;
&lt;p&gt;In netfs_perform_write(), when the file is marked NETFS_ICTX_WRITETHROUGH
or O_*SYNC or RWF_*SYNC was specified, write-through caching is performed
on a buffered file.  When setting up for write-through, we flush any
conflicting writes in the region and wait for the write to complete,
failing if there&amp;#39;s a write error to return.&lt;/p&gt;
&lt;p&gt;The issue arises if we&amp;#39;re writing at or above the EOF position because we
skip the flush and - more importantly - the wait.  This becomes a problem
if there&amp;#39;s a partial folio at the end of the file that is being written out
and we want to make a write to it too.  Both the already-running write and
the write we start both want to clear the writeback mark, but whoever is
second causes a warning looking something like:&lt;/p&gt;
&lt;p&gt;------------[ cut here ]------------
    R=00000012: folio 11 is not under writeback
    WARNING: CPU: 34 PID: 654 at fs/netfs/write_collect.c:105
    ...
    CPU: 34 PID: 654 Comm: kworker/u386:27 Tainted: G S ...
    ...
    Workqueue: events_unbound netfs_write_collection_worker
    ...
    RIP: 0010:netfs_writeback_lookup_folio&lt;/p&gt;
&lt;p&gt;Fix this by making the flush-and-wait unconditional.  It will do nothing if
there are no folios in the pagecache and will return quickly if there are
no folios in the region specified.&lt;/p&gt;
&lt;p&gt;Further, move the WBC attachment above the flush call as the flush is going
to at…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2024-36001</guid>
    </item>
  </channel>
</rss>
