CVE-2026-43187

In the Linux kernel, the following vulnerability has been resolved:

xfs: delete attr leaf freemap entries when empty

Back in commit 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size

underflow"), Brian Foster observed that it's possible for a small

freemap at the end of the end of the xattr entries array to experience

a size underflow when subtracting the space consumed by an expansion of

the entries array. There are only three freemap entries, which means

that it is not a complete index of all free space in the leaf block.

This code can leave behind a zero-length freemap entry with a nonzero

base. Subsequent setxattr operations can increase the base up to the

point that it overlaps with another freemap entry. This isn't in and of

itself a problem because the code in _leaf_add that finds free space

ignores any freemap entry with zero size.

However, there's another bug in the freemap update code in _leaf_add,

which is that it fails to update a freemap entry that begins midway

through the xattr entry that was just appended to the array. That can

result in the freemap containing two entries with the same base but

different sizes (0 for the "pushed-up" entry, nonzero for the entry

that's actually tracking free space). A subsequent _leaf_add can then

allocate xattr namevalue entries on top of the entries array, leading to

data loss. But fixing that is for later.

For now, eliminate the possibility of confusion by zeroing out the base

of any freemap entry that has zero size. Because the freemap is not

intended to be a complete index of free space, a subsequent failure to

find any free space for a new xattr will trigger block compaction, which

regenerates the freemap.

It looks like this bug has been in the codebase for quite a long time.