Description
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 there's 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! That's 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,
it's 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] hasn't 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.
Published: 2026-05-06
Score: 8.8 High
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The XFS filesystem uses a freemap array in leaf blocks to track free space. When multiple extended attributes are added, entries in this freemap are not correctly updated, causing the array and the claimed free space to occupy the same region. This misalignment triggers an internal assertion and forces the kernel to panic, shutting down the system. The result is a denial of service to all processes relying on the affected XFS node.

Affected Systems

Linux kernel installations that deploy the XFS filesystem and still contain the old freemap adjustment logic. No explicit version range is provided, so any system running an unpatched kernel prior to the commit that introduced the fix is potentially affected.

Risk and Exploitability

The CVSS score of 8.8 indicates a high impact. The EPSS score is < 1%, and the vulnerability is not listed in the CISA KEV catalog. Attackers would need local access to create or modify extended attributes on a writable XFS filesystem. The flaw leads to a kernel panic but does not permit arbitrary code execution. While this limits the threat to compromised or compromised‑accessible hosts, the severity of a kernel crash warrants prompt remediation.

Generated by OpenCVE AI on May 13, 2026 at 22:32 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the Linux kernel to a release that includes the freemap adjustment fix (e.g., commit 24ce718).
  • If an immediate upgrade is impossible, limit the use of large or frequent extended attributes on critical XFS filesystems, or disable xattr creation for selected files or directories via filesystem permissions or application configuration.
  • Continuously monitor kernel logs such as dmesg and XFS‑specific error logs for assertions or panics, and take corrective action if such errors appear.

Generated by OpenCVE AI on May 13, 2026 at 22:32 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DLA Debian DLA DLA-4606-1 linux security update
History

Wed, 13 May 2026 21:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-787
CPEs cpe:2.3:o:linux:linux_kernel:2.6.12:-:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:2.6.12:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:2.6.12:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:2.6.12:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:2.6.12:rc5:*:*:*:*:*:*

Fri, 08 May 2026 13:00:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

 cvssV3_1

{'score': 8.8, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}

Thu, 07 May 2026 04:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-119
CWE-665

Thu, 07 May 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-131
References
Metrics threat_severity

None

 cvssV3_1

{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

threat_severity

Important

Wed, 06 May 2026 18:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-119
CWE-665

Wed, 06 May 2026 12:15:00 +0000

Type Values Removed Values Added
Description 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 there's 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! That's 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, it's 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] hasn't 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.
Title xfs: fix freemap adjustments when adding xattrs to leaf blocks
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-05-11T22:18:53.079Z

Reserved: 2026-05-01T14:12:55.990Z

Link: CVE-2026-43158

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Analyzed

Published: 2026-05-06T12:16:33.697

Modified: 2026-05-13T21:20:41.473

Link: CVE-2026-43158

cve-icon Redhat

Severity : Important

Publid Date: 2026-05-06T00:00:00Z

Links: CVE-2026-43158 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-05-13T22:45:06Z

Weaknesses