CVE-2026-80536 in Linux
Summary
by MITRE • 08/26/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/26/2026
The Linux kernel's XFS filesystem implementation contained a critical out-of-bounds memory write vulnerability within its log recovery mechanism, specifically in the xlog_recover_do_reg_buffer function. This flaw arises during the process of replaying dirty regions from buffer log items into their corresponding buffers when mounting a filesystem image. The core technical issue lies in how the destination offset and copy length are derived for a memcpy operation that updates the buffer with logged changes. These parameters, representing the bit position within the dirty bitmap and the number of bits to copy respectively, are controlled by data stored on disk as part of the filesystem metadata. Crucially, while these values define the scope of the memory write, they were not rigorously validated against the actual allocated size of the target buffer in production builds.
The vulnerability is rooted in a defensive programming practice that relied exclusively on an ASSERT macro to bound-check the copy operation. In debug-enabled kernel configurations, this assertion would trigger and halt execution if invalid parameters were detected. However, because assertions are compiled out in standard production kernels where CONFIG_XFS_DEBUG is disabled, this safety check effectively vanished for most users. Consequently, a malicious actor could craft a filesystem image containing log entries with a small buffer length but a dirty bitmap indicating modifications at offsets or sizes exceeding that limit. When such an image was mounted and the kernel attempted to recover its journal logs, it would execute the memcpy without proper bounds verification, leading to a slab-out-of-bounds write.
This memory corruption allows for potential arbitrary code execution or system instability by overwriting adjacent kernel heap structures during the mount-time log recovery phase. The threat model aligns with scenarios where an attacker can provide a crafted filesystem image to be mounted by a privileged user or service, such as through removable media or network-mounted shares if access controls are insufficiently restrictive. Although XFS has other mechanisms to guard against malicious filesystems, this specific path in the log recovery code lacked adequate validation for the relationship between the logged buffer length and the bitmap-defined dirty regions. The lack of runtime checks meant that crafted inputs could silently corrupt kernel memory without immediate detection, potentially leading to privilege escalation or denial of service depending on what heap data was overwritten.
The resolution involves replacing the ineffective ASSERT with a robust XFS_IS_CORRUPT check that actively validates the bounds before performing the copy operation. If the calculated destination offset plus the number of bits exceeds the buffer's allocated length, the recovery process is aborted for that specific buffer and returns an -EFSCORRUPTED error code. This approach adheres to the validate-and-fail idiom already established in other parts of the XFS log recovery subsystem, such as xlog_recover_do_inode_buffer. By ensuring that invalid metadata results in a clean failure rather than undefined behavior, the patch eliminates the possibility of heap corruption during mount operations. The function was also made static and its error propagation updated to ensure callers properly handle the recovery failure, maintaining system integrity even when encountering malformed or malicious filesystem images.
From a classification perspective, this vulnerability is best described as an Out-of-Bounds Write (CWE-787) resulting from insufficient validation of input data derived from untrusted sources, specifically disk-based metadata in this context. The attack vector involves manipulating file system structures to trigger memory corruption during initialization phases, which can be categorized under the ATT&CK technique for Exploitation for Privilege Escalation if the heap overwrite targets sensitive kernel objects, or generally as part of Initial Access via malicious removable media or network shares depending on deployment contexts. Mitigation strategies primarily involve applying the provided kernel patch to enforce strict bounds checking during log recovery. Additionally, system administrators should ensure that only trusted filesystem images are mounted and consider implementing additional access controls for mount operations where feasible to limit exposure to crafted storage devices.