AZL-97851

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.