Skip to main content
VulnerabilityPublished Updated

CVE-2026-43187: Linux kernel · xfs: delete attr leaf freemap entries when empty

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · CVSS 8.8 High · fixed in ffaf5c99d0f862db021fb1af8b813c1416b1beb2 : patch Linux kernel soon.

Data as of 26 Oct 2026, 12:55 UTC

CVSS 3.1 base score
8.8High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.4% chance of exploitation in 30 days – higher than 40% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers cannot reliably automate steps 1–4 of the kill chain
Technical impact
Total control over the software or total information disclosure

CISA SSVC assessment, 2026-10-16.

Patch
Available – fixed in ffaf5c99d0f862db021fb1af8b813c1416b1beb2, f31a8334e1c54b126fcecf98645a49b6bc5ad399, f3c0d1fc1eadbb4adbee5ab7757d41d35f48325b +5
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 6 May 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < ffaf5c99d0f862db021fb1af8b813c1416b1beb2
Fixed in
  • ffaf5c99d0f862db021fb1af8b813c1416b1beb2
LinuxLinuxAffected
  • ≥ 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < f31a8334e1c54b126fcecf98645a49b6bc5ad399
Fixed in
  • f31a8334e1c54b126fcecf98645a49b6bc5ad399
LinuxLinuxAffected
  • ≥ 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < f3c0d1fc1eadbb4adbee5ab7757d41d35f48325b
Fixed in
  • f3c0d1fc1eadbb4adbee5ab7757d41d35f48325b
LinuxLinuxAffected
  • ≥ 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < e1b8c6452ee99a30e188a88f3f3f804fb1c6004a
Fixed in
  • e1b8c6452ee99a30e188a88f3f3f804fb1c6004a
LinuxLinuxAffected
  • ≥ 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < aa9083d97e2157da3c6fb45ddb1a97af7f188f7f
Fixed in
  • aa9083d97e2157da3c6fb45ddb1a97af7f188f7f
LinuxLinuxAffected
  • ≥ 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < a631899025d47ea1aa6464d76db5b4d3b6d196fd
Fixed in
  • a631899025d47ea1aa6464d76db5b4d3b6d196fd

Description

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.

References

Community reviews

Loading reviews…