CVE-2026-43158

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

xfs: fix freemap adjustments when adding xattrs to leaf blocks

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:

ASSERT(ichdr->firstused >= ichdr->count * sizeof(xfs_attr_leaf_entry_t) + xfs_attr3_leaf_hdr_size(leaf));

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.

At the start of xfs_attr3_leaf_add_work, the freemap looks like this:

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

where rhs 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 theres free space starting at byte 388!

By the end of the function, the freemap is in worse shape:

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

Important note: 388 is not aligned with the entries array element size of 8 bytes.

Based on the incorrect freemap, the name area starts at byte 440, which is below the end of the entries array! Thats why the assertion triggers and the filesystem shuts down.

How did we end up here? First, recall from the previous patch that the freemap array in an xattr leaf block is not intended to be a comprehensive map of all free space in the leaf block. In other words, its perfectly legal to have a leaf block with:

• 376 bytes in use by the entries array
• freemap[0] has [base = 376, size = 8]
• freemap[1] has [base = 388, size = 1500]
• the space between 376 and 388 is free, but the freemap stopped tracking that some time ago

If we add one xattr, the entries array grows to 384 bytes, and freemap[0] becomes [base = 384, size = 0]. So far, so good. But if we add a second xattr, the entries array grows to 392 bytes, and freemap[0] gets pushed up to [base = 392, size = 0]. This is bad, because freemap[1] hasnt been updated, and now the entries array and the free space claim the same space.

The fix here is to adjust all freemap entries so that none of them collide with the entries array. Note that this fix relies on commit 2a2b5932db6758 (xfs: fix attr leaf header freemap.size underflow) and the previous patch that resets zero length freemap entries to have base = 0.

Weakness

The product writes data past the end, or before the beginning, of the intended buffer.

Affected Software

Potential Mitigations

• Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

• For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer.

• Be wary that a language’s interface to native code may still be subject to overflows, even if the language itself is theoretically safe.

• Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

• Examples include the Safe C String Library (SafeStr) by Messier and Viega [REF-57], and the Strsafe.h library from Microsoft [REF-56]. These libraries provide safer versions of overflow-prone string-handling functions.

• Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking.

• D3-SFCV (Stack Frame Canary Validation) from D3FEND [REF-1334] discusses canary-based detection in detail.

• Consider adhering to the following rules when allocating and managing an application’s memory:

• Run or compile the software using features or extensions that randomly arrange the positions of a program’s executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.

• Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as “rebasing” (for Windows) and “prelinking” (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking.

• For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].

• Use a CPU and operating system that offers Data Execution Protection (using hardware NX or XD bits) or the equivalent techniques that simulate this feature in software, such as PaX [REF-60] [REF-61]. These techniques ensure that any instruction executed is exclusively at a memory address that is part of the code segment.

• For more information on these techniques see D3-PSEP (Process Segment Execution Prevention) from D3FEND [REF-1336].

References

• https://git.kernel.org/stable/c/24ce71852f2cee6581e2cbebc15489ed52bf63b7
• https://git.kernel.org/stable/c/38613c01f69e1e77e6b8acab1e8ac665d01c2f15
• https://git.kernel.org/stable/c/3eefc0c2b78444b64feeb3783c017d6adc3cd3ce
• https://git.kernel.org/stable/c/43f3b18679615a93bd848afde3602ba160637a46
• https://git.kernel.org/stable/c/6a8737afbccc340e718e0b22577312826390be8b
• https://git.kernel.org/stable/c/a396b3d73d51355e50acdb403ba9c4cae4c1174e
• https://git.kernel.org/stable/c/d08976725355b9d54d8332fce223fa281cc304a5
• https://git.kernel.org/stable/c/ef42a8766ff3fdf51cf72fb36d0859c09d134478