In the Linux kernel, the following vulnerability has been resolved:
xfs: bounds-check buffer log item's dirty bitmap
xlogrecoverdoregbuffer() 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 blflen) 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 blflen 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 XFSISCORRUPT() check that aborts recovery of the buffer with -EFSCORRUPTED, consistent with the validate-and-fail idiom already used in xlogrecoverdoinodebuffer() and xfsdquotitemrecover.c. xlogrecoverdoreg_buffer() therefore becomes STATIC int and its three callers propagate the error.
Found and confirmed with KASAN on a CONFIGXFSDEBUG=n build: the crafted image trips a slab-out-of-bounds write before this change and fails recovery cleanly with -EFSCORRUPTED after it.
{
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/80xxx/CVE-2026-80536.json",
"cna_assigner": "Linux"
}