CVE-2026-43187

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: delete attr leaf freemap entries when empty<br /> <br /> Back in commit 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size<br /> underflow"), Brian Foster observed that it&amp;#39;s possible for a small<br /> freemap at the end of the end of the xattr entries array to experience<br /> a size underflow when subtracting the space consumed by an expansion of<br /> the entries array. There are only three freemap entries, which means<br /> that it is not a complete index of all free space in the leaf block.<br /> <br /> This code can leave behind a zero-length freemap entry with a nonzero<br /> base. Subsequent setxattr operations can increase the base up to the<br /> point that it overlaps with another freemap entry. This isn&amp;#39;t in and of<br /> itself a problem because the code in _leaf_add that finds free space<br /> ignores any freemap entry with zero size.<br /> <br /> However, there&amp;#39;s another bug in the freemap update code in _leaf_add,<br /> which is that it fails to update a freemap entry that begins midway<br /> through the xattr entry that was just appended to the array. That can<br /> result in the freemap containing two entries with the same base but<br /> different sizes (0 for the "pushed-up" entry, nonzero for the entry<br /> that&amp;#39;s actually tracking free space). A subsequent _leaf_add can then<br /> allocate xattr namevalue entries on top of the entries array, leading to<br /> data loss. But fixing that is for later.<br /> <br /> For now, eliminate the possibility of confusion by zeroing out the base<br /> of any freemap entry that has zero size. Because the freemap is not<br /> intended to be a complete index of free space, a subsequent failure to<br /> find any free space for a new xattr will trigger block compaction, which<br /> regenerates the freemap.<br /> <br /> It looks like this bug has been in the codebase for quite a long time.