CVE-2026-43187High· 8.8▾ TwilightIn 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 po…
▾ Twilight zone — High severity, or a signal on a lesser flaw
impact 48.4 · likelihood 0.1 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Stakeholder-Specific Vulnerability Categorization from CISA's ADP record at CVE.org: whether exploitation is observed, whether an attack can be automated, and how much of the system is at stake. The CVSS score shown above comes from the assigning CNA record, not NVD.
Exploit-prediction probability, daily snapshots since Oct 16.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via CVEORG
0.7%
Last analysed / modified upstream
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.
Linux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < f3c0d1fc1eadbb4adbee5ab7757d41d35f48325bLinux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < aa9083d97e2157da3c6fb45ddb1a97af7f188f7fLinux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < a631899025d47ea1aa6464d76db5b4d3b6d196fdLinux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < ffaf5c99d0f862db021fb1af8b813c1416b1beb2Linux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < e1b8c6452ee99a30e188a88f3f3f804fb1c6004aLinux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < f31a8334e1c54b126fcecf98645a49b6bc5ad399Linux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < 479b05fc3ee272090f671b06a41f3da8aa78eeceLinux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < 6f13c1d2a6271c2e73226864a0e83de2770b6f34Linux 2.6.12Refer to the linked advisories for vendor-supplied fixes and affected version ranges.
Connected by shared product, vendor, weakness, or advisory.
CVE-2026-99118Nonedrm/i915/dmc: Harden DMC firmware payload parsing
CVE-2026-99117Nonenet: bridge: mcast: don't truncate the port group walk on teardown
CVE-2026-99121Noneipv4: avoid divide by zero in fib_rebalance
CVE-2026-99120NoneKVM: x86/mmu: Cope with the SS bit being set in #NPF exit codes
CVE-2026-99119Nonedrm/amdgpu/userq: actually validate userq BOs
CVE-2026-99123Nonevsock/virtio: validate packet source for connected sockets