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.
Published: 2026-08-26
Score: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The Linux kernel contains a flaw where the function responsible for replaying XFS log items writes data into a buffer without proper bounds checking. An attacker can construct a filesystem image that advertises a small buffer length while including bitmap entries that reference offsets beyond that length. During mount-time recovery, the memcpy call will then write past the allocated buffer, corrupting adjacent kernel heap memory. If the corruption is exploited, it can lead to arbitrary code execution with system privileges or a denial‑of‑service by crashing the kernel.

Affected Systems

Any Linux kernel implementation that includes the XFS filesystem with a version prior to this fix. The Advisory does not list a specific affected version, so all builds using XFS are potentially vulnerable until the patch is applied.

Risk and Exploitability

The vulnerability is considered severe because it corrupts kernel memory; however it is not listed in the CISA KEV catalog and no EPSS score is available. Exploitation requires an attacker to craft and mount a malicious filesystem image, meaning the threat is limited to environments that allow untrusted images to be mounted. Once mounted, the flaw can be triggered automatically during log recovery, potentially granting kernel‑level privilege escalation or causing a system crash.

Generated by OpenCVE AI on August 26, 2026 at 15:40 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply the latest Linux kernel update that includes the XFS bounds‑check fix
  • If an immediate kernel upgrade is not feasible, avoid mounting untrusted or unknown XFS filesystems; consider mounting known good images only or use read‑only options to reduce risk
  • If XFS support is not required for a system, disable XFS kernel support to remove the attack surface

Generated by OpenCVE AI on August 26, 2026 at 15:40 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 26 Aug 2026 16:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-122

Wed, 26 Aug 2026 14:45:00 +0000

Type Values Removed Values Added
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.
Title xfs: bounds-check buffer log item's dirty bitmap
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-26T14:37:11.584Z

Reserved: 2026-08-26T14:34:25.765Z

Link: CVE-2026-80536

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-08-26T15:17:07.777

Modified: 2026-08-26T15:17:07.777

Link: CVE-2026-80536

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-08-26T16:45:08Z

Weaknesses
  • CWE-122

    Heap-based Buffer Overflow