CVE-2026-80536xfs: bounds-check buffer log item's dirty bitmap
Updated under an hour ago ()
Does this affect you?
It affects Linux. Add what you run to find out whether that includes you.
No exploitation reported and no EPSS estimate yet.
Do this next
Free account, 1 product
In the Linux kernel, the following vulnerability has been resolved: xfs: bounds-check buffer log item's dirty bitmap xlog_recover_do_reg_buffer() replays each dirty region described by a buffer log item's bitmap into the buffer read for that item: memcpy(xfs_buf_offset(bp, (uint)bit << XFS_BLF_SHIFT), item->ri_buf[i].iov_base, nbits << XFS_BLF_SHIFT); The destination offset (bit/nbits, from the logged dirty bitmap) and the buffer size (from the logged blf_len) are both attacker-controlled and otherwise unrelated, yet the only thing bounding the copy is an ASSERT(), which compiles away on production kernels. A crafted image logging a small blf_len together with a bitmap bit past the end of that buffer drives the memcpy() past the buffer's allocation, corrupting adjacent kernel heap during mount-time log recovery. This is reachable by anyone who can get a crafted image mounted -- the malicious-filesystem threat model XFS already guards against elsewhere. Turn the ASSERT() into a real XFS_IS_CORRUPT() check that aborts recovery of the buffer with -EFSCORRUPTED, consistent with the validate-and-fail idiom already used in xlog_recover_do_inode_buffer() and xfs_dquot_item_recover.c. xlog_recover_do_reg_buffer() therefore becomes STATIC int and its three callers propagate the error. Found and confirmed with KASAN on a CONFIG_XFS_DEBUG=n build: the crafted image trips a slab-out-of-bounds write before this change and fails recovery cleanly with -EFSCORRUPTED after it.
- CVSS
- 8.4 HIGH (v3.1, CNA)CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
- Weakness (CWE)
- Not given
- Known exploited
- Not in CISA's KEV catalog
- EPSS (exploitation in the next 30 days)
- Not loaded for this CVE
- Assigned by
- Linux
- NVD analysis
- Received
- Record last updated
- Oct 16, 2026
- First seen by InfoSec Signals
- Oct 9, 2026
Affected products
Linux Linux linux:linux (from the name) | from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 before acb4e26295e7f0e685815a3fd3d70bd8329cefa1; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 before f3859c35a4fbc1c1c58431f684f808e43696891d; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 before f7b5fa83e2c192be922121b764415fa8c7549ea1; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 before b7528b42813f02724a78fce1da24d69d1bfc4d38; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 before 7e32d4eebae6ca24f8a673c107fd7eca1f47afc2; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 before f8288214459ead7e87d26e5822f62c14a4f2ed6b; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 before edaf5b6bd625356893da20d69a259b34a9de2694; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 before 813f8136a2ce1fee266d02a7df73db6e8a541604 | CNA record |
References
- https://git.kernel.org/stable/c/acb4e26295e7f0e685815a3fd3d70bd8329cefa1
- https://git.kernel.org/stable/c/f3859c35a4fbc1c1c58431f684f808e43696891d
- https://git.kernel.org/stable/c/f7b5fa83e2c192be922121b764415fa8c7549ea1
- https://git.kernel.org/stable/c/b7528b42813f02724a78fce1da24d69d1bfc4d38
- https://git.kernel.org/stable/c/7e32d4eebae6ca24f8a673c107fd7eca1f47afc2
- https://git.kernel.org/stable/c/f8288214459ead7e87d26e5822f62c14a4f2ed6b
- https://git.kernel.org/stable/c/edaf5b6bd625356893da20d69a259b34a9de2694
- https://git.kernel.org/stable/c/813f8136a2ce1fee266d02a7df73db6e8a541604
The CVE record on cve.org NVD's entry
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.