<?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:19:05 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-43158 — xfs: fix freemap adjustments when adding xattrs to leaf blocks</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-43158</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;xfs: fix freemap adjustments when adding xattrs to leaf blocks&lt;/p&gt;
&lt;p&gt;xfs/592 and xfs/794 both trip this assertion in the leaf block freemap
adjustment code after ~20 minutes of running on my test VMs:&lt;/p&gt;
&lt;p&gt;ASSERT(ichdr-&amp;gt;firstused &amp;gt;= ichdr-&amp;gt;count * sizeof(xfs_attr_leaf_entry_t)
					+ xfs_attr3_leaf_hdr_size(leaf));&lt;/p&gt;
&lt;p&gt;Upon enabling quite a lot more debugging code, I narrowed this down to
fsstress trying to set a local extended attribute with namelen=3 and
valuelen=71.  This results in an entry size of 80 bytes.&lt;/p&gt;
&lt;p&gt;At the start of xfs_attr3_leaf_add_work, the freemap looks like this:&lt;/p&gt;
&lt;p&gt;i 0 base 448 size 0 rhs 448 count 46
i 1 base 388 size 132 rhs 448 count 46
i 2 base 2120 size 4 rhs 448 count 46
firstused = 520&lt;/p&gt;
&lt;p&gt;where &amp;#34;rhs&amp;#34; is the first byte past the end of the leaf entry array.
This is inconsistent -- the entries array ends at byte 448, but
freemap[1] says there&amp;#39;s free space starting at byte 388!&lt;/p&gt;
&lt;p&gt;By the end of the function, the freemap is in worse shape:&lt;/p&gt;
&lt;p&gt;i 0 base 456 size 0 rhs 456 count 47
i 1 base 388 size 52 rhs 456 count 47
i 2 base 2120 size 4 rhs 456 count 47
firstused = 440&lt;/p&gt;
&lt;p&gt;Important note: 388 is not aligned with the entries array element size
of 8 bytes.&lt;/p&gt;
&lt;p&gt;Based on the incorrect freemap, the name area starts at byte 440, which
is below the end of the entries array!  That&amp;#39;s why the assertion
triggers and the filesystem shuts down.&lt;/p&gt;
&lt;p&gt;How did we end up here?  First, recall from the previous patch that the
freema…&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;xfs: fix freemap adjustments when adding xattrs to leaf blocks&lt;/p&gt;
&lt;p&gt;xfs/592 and xfs/794 both trip this assertion in the leaf block freemap
adjustment code after ~20 minutes of running on my test VMs:&lt;/p&gt;
&lt;p&gt;ASSERT(ichdr-&amp;gt;firstused &amp;gt;= ichdr-&amp;gt;count * sizeof(xfs_attr_leaf_entry_t)
					+ xfs_attr3_leaf_hdr_size(leaf));&lt;/p&gt;
&lt;p&gt;Upon enabling quite a lot more debugging code, I narrowed this down to
fsstress trying to set a local extended attribute with namelen=3 and
valuelen=71.  This results in an entry size of 80 bytes.&lt;/p&gt;
&lt;p&gt;At the start of xfs_attr3_leaf_add_work, the freemap looks like this:&lt;/p&gt;
&lt;p&gt;i 0 base 448 size 0 rhs 448 count 46
i 1 base 388 size 132 rhs 448 count 46
i 2 base 2120 size 4 rhs 448 count 46
firstused = 520&lt;/p&gt;
&lt;p&gt;where &amp;#34;rhs&amp;#34; is the first byte past the end of the leaf entry array.
This is inconsistent -- the entries array ends at byte 448, but
freemap[1] says there&amp;#39;s free space starting at byte 388!&lt;/p&gt;
&lt;p&gt;By the end of the function, the freemap is in worse shape:&lt;/p&gt;
&lt;p&gt;i 0 base 456 size 0 rhs 456 count 47
i 1 base 388 size 52 rhs 456 count 47
i 2 base 2120 size 4 rhs 456 count 47
firstused = 440&lt;/p&gt;
&lt;p&gt;Important note: 388 is not aligned with the entries array element size
of 8 bytes.&lt;/p&gt;
&lt;p&gt;Based on the incorrect freemap, the name area starts at byte 440, which
is below the end of the entries array!  That&amp;#39;s why the assertion
triggers and the filesystem shuts down.&lt;/p&gt;
&lt;p&gt;How did we end up here?  First, recall from the previous patch that the
freema…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-43158</guid>
    </item>
  </channel>
</rss>
