<?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:54:43 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-72367 — iomap: guard io_size EOF trim against concurrent truncate underflow</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-72367</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;iomap: guard io_size EOF trim against concurrent truncate underflow&lt;/p&gt;
&lt;p&gt;iomap: fix zero padding data issue in concurrent append writes
changed ioend accounting so that io_size tracks only valid data
within EOF.  This trims io_size when a writeback range extends
past end_pos:&lt;/p&gt;
&lt;p&gt;ioend-&amp;gt;io_size += map_len;
    if (ioend-&amp;gt;io_offset + ioend-&amp;gt;io_size &amp;gt; end_pos)
        ioend-&amp;gt;io_size = end_pos - ioend-&amp;gt;io_offset;&lt;/p&gt;
&lt;p&gt;However, if end_pos ends up below ioend-&amp;gt;io_offset, the subtraction
becomes negative and is stored in size_t io_size, causing an unsigned
wrap to a huge value.  This can happen when writeback continues past
byte-level EOF up to a block-aligned range, or when a concurrent
truncate shrinks the file after end_pos was sampled in
iomap_writeback_handle_eof().&lt;/p&gt;
&lt;p&gt;A wrapped io_size can mislead append detection and corrupt
completion-time size handling, since filesystem end_io paths consume
io_size for decisions such as on-disk EOF updates and unwritten/COW
completion ranges.&lt;/p&gt;
&lt;p&gt;Fix this by clamping io_size to zero when EOF has moved to or before
the ioend start offset.  This preserves the original intent of trimming
io_size to valid in-EOF data while avoiding the underflow.&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;iomap: guard io_size EOF trim against concurrent truncate underflow&lt;/p&gt;
&lt;p&gt;iomap: fix zero padding data issue in concurrent append writes
changed ioend accounting so that io_size tracks only valid data
within EOF.  This trims io_size when a writeback range extends
past end_pos:&lt;/p&gt;
&lt;p&gt;ioend-&amp;gt;io_size += map_len;
    if (ioend-&amp;gt;io_offset + ioend-&amp;gt;io_size &amp;gt; end_pos)
        ioend-&amp;gt;io_size = end_pos - ioend-&amp;gt;io_offset;&lt;/p&gt;
&lt;p&gt;However, if end_pos ends up below ioend-&amp;gt;io_offset, the subtraction
becomes negative and is stored in size_t io_size, causing an unsigned
wrap to a huge value.  This can happen when writeback continues past
byte-level EOF up to a block-aligned range, or when a concurrent
truncate shrinks the file after end_pos was sampled in
iomap_writeback_handle_eof().&lt;/p&gt;
&lt;p&gt;A wrapped io_size can mislead append detection and corrupt
completion-time size handling, since filesystem end_io paths consume
io_size for decisions such as on-disk EOF updates and unwritten/COW
completion ranges.&lt;/p&gt;
&lt;p&gt;Fix this by clamping io_size to zero when EOF has moved to or before
the ioend start offset.  This preserves the original intent of trimming
io_size to valid in-EOF data while avoiding the underflow.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-72367</guid>
    </item>
  </channel>
</rss>
