Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.4",
  "pubDate": "2026-08-26T15:17:07.777Z",
  "pubdate": "2026-08-26T15:17:07.777Z",
  "executiveSummary": "A critical out-of-bounds heap memory corruption vulnerability exists in the Linux kernel XFS filesystem implementation during the log recovery process. The vulnerability stems from insufficient validation of buffer log items, specifically regarding the dirty bitmap offsets and buffer lengths.\nAn attacker can provide a maliciously crafted XFS filesystem image that, when mounted, triggers an out-of-bounds write via the memcpy operation in xlog_recover_do_reg_buffer(). This flaw allows for heap memory corruption by manipulating fields within the buffer log item that are not adequately constrained by production-level code.\nThe impact is significant, as successful exploitation can lead to kernel-level memory corruption, system instability, or potential arbitrary code execution depending on the heap layout. This vulnerability is reachable by any user capable of mounting a filesystem, fitting the malicious-filesystem threat model. The vulnerability is mitigated by replacing existing debug-only assertions with rigorous runtime corruption checks that abort recovery upon detecting invalid metadata.",
  "technicalDetails": "The vulnerability resides within the xlog_recover_do_reg_buffer() function of the XFS log recovery subsystem. During the log replay process, the kernel interprets buffer log items that describe dirty regions of an XFS buffer. These items include a dirty bitmap that specifies which portions of the buffer must be updated with data from the log.\nThe root cause is a lack of runtime bounds checking on the destination offset and the length of the memory copy operation. Specifically, the function performs a memcpy() where the destination address is calculated using the dirty bitmap's bit offset (shifted by XFS_BLF_SHIFT) and the source data is provided by the log. Previously, this operation relied exclusively on an ASSERT() statement to verify that the copy remained within the bounds of the allocated buffer. Because ASSERT() macros are compiled out in production (non-debug) kernel builds, the implementation failed to validate the relationship between the attacker-controlled 'blf_len' (the buffer size) and the 'bit/nbits' offsets derived from the log item's dirty bitmap.\nAn attacker can exploit this by crafting a malicious filesystem image containing a log entry where the dirty bitmap indicates an offset that extends beyond the end of the destination buffer's allocated heap memory. During mount-time log recovery, the kernel blindly executes the memcpy(), resulting in an out-of-bounds heap write. This operation corrupts adjacent kernel heap objects. Because the kernel allocates these buffers via the slab allocator, the corruption can overwrite sensitive kernel metadata, function pointers, or data structures, potentially leading to privilege escalation or system crashes.\nThe flaw was confirmed using KASAN on production-configured kernels (CONFIG_XFS_DEBUG=n), which demonstrated that the crafted image triggers a slab-out-of-bounds write. The remediation involves replacing the insufficient ASSERT() with an XFS_IS_CORRUPT() check. This forces the filesystem driver to validate the input against the actual buffer size and abort the recovery process with an -EFSCORRUPTED error code if an inconsistency is detected. By promoting xlog_recover_do_reg_buffer() to a STATIC int and propagating these error returns through its callers, the filesystem ensures that malicious metadata is rejected early, preventing memory corruption before the invalid data can be committed to the kernel's memory space."
}