CVE-2026-80536

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.