CVE-2026-43158

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: fix freemap adjustments when adding xattrs to leaf blocks<br /> <br /> xfs/592 and xfs/794 both trip this assertion in the leaf block freemap<br /> adjustment code after ~20 minutes of running on my test VMs:<br /> <br /> ASSERT(ichdr-&gt;firstused &gt;= ichdr-&gt;count * sizeof(xfs_attr_leaf_entry_t)<br /> + xfs_attr3_leaf_hdr_size(leaf));<br /> <br /> Upon enabling quite a lot more debugging code, I narrowed this down to<br /> fsstress trying to set a local extended attribute with namelen=3 and<br /> valuelen=71. This results in an entry size of 80 bytes.<br /> <br /> At the start of xfs_attr3_leaf_add_work, the freemap looks like this:<br /> <br /> i 0 base 448 size 0 rhs 448 count 46<br /> i 1 base 388 size 132 rhs 448 count 46<br /> i 2 base 2120 size 4 rhs 448 count 46<br /> firstused = 520<br /> <br /> where "rhs" is the first byte past the end of the leaf entry array.<br /> This is inconsistent -- the entries array ends at byte 448, but<br /> freemap[1] says there&amp;#39;s free space starting at byte 388!<br /> <br /> By the end of the function, the freemap is in worse shape:<br /> <br /> i 0 base 456 size 0 rhs 456 count 47<br /> i 1 base 388 size 52 rhs 456 count 47<br /> i 2 base 2120 size 4 rhs 456 count 47<br /> firstused = 440<br /> <br /> Important note: 388 is not aligned with the entries array element size<br /> of 8 bytes.<br /> <br /> Based on the incorrect freemap, the name area starts at byte 440, which<br /> is below the end of the entries array! That&amp;#39;s why the assertion<br /> triggers and the filesystem shuts down.<br /> <br /> How did we end up here? First, recall from the previous patch that the<br /> freemap array in an xattr leaf block is not intended to be a<br /> comprehensive map of all free space in the leaf block. In other words,<br /> it&amp;#39;s perfectly legal to have a leaf block with:<br /> <br /> * 376 bytes in use by the entries array<br /> * freemap[0] has [base = 376, size = 8]<br /> * freemap[1] has [base = 388, size = 1500]<br /> * the space between 376 and 388 is free, but the freemap stopped<br /> tracking that some time ago<br /> <br /> If we add one xattr, the entries array grows to 384 bytes, and<br /> freemap[0] becomes [base = 384, size = 0]. So far, so good. But if we<br /> add a second xattr, the entries array grows to 392 bytes, and freemap[0]<br /> gets pushed up to [base = 392, size = 0]. This is bad, because<br /> freemap[1] hasn&amp;#39;t been updated, and now the entries array and the free<br /> space claim the same space.<br /> <br /> The fix here is to adjust all freemap entries so that none of them<br /> collide with the entries array. Note that this fix relies on commit<br /> 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size underflow") and<br /> the previous patch that resets zero length freemap entries to have<br /> base = 0.