CVE-2026-80536: xfs: bounds-check buffer log item's dirty bitmap
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(xfsbufoffset(bp, (uint)bit << XFSBLFSHIFT), item->ribuf[i].iovbase, nbits << XFSBLFSHIFT);
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. xlogrecoverdoregbuffer() 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Update the Linux kernel XFS recovery code so the ASSERT() bounding the memcpy() for the buffer log item's dirty bitmap is replaced by an XFS_IS_CORRUPT() check that aborts recovery with -EFSCORRUPTED (as described: validate-and-fail behavior consistent with xlog_recover_do_inode_buffer() / xlog_recover_do_reg_buffer()).
Linux kernel XFS ASSERT() in xfs_dquot_item_recover.c recovery path for buffer log dirty bitmap bounds = Replaced with real XFS_IS_CORRUPT() check that aborts recovery
Event History
Frequently Asked Questions
Which systems should be prioritized for remediation?
Systems that can mount XFS filesystem images from untrusted or attacker-controlled sources are exposed during mount-time log recovery. The issue is reachable by anyone able to get a crafted image mounted.
Why is the existing assertion not an effective production safeguard?
The copy was bounded only by an ASSERT(), which compiles away in production kernels. As a result, malformed logged bitmap data could drive a memcpy past the allocated buffer.
How does the resolved behavior handle malformed log data?
It performs a real corruption check on the dirty-bitmap copy bounds. If validation fails, recovery of the buffer is aborted with -EFSCORRUPTED rather than continuing with an out-of-bounds copy.