Strix
63.5K

CVE-2026-80536

HIGHCVSS 8.4/10

Last modified

CVE-2026-80536 is a high-severity vulnerability rated 8.4/10 on the CVSS scale. 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.

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.

Metrics

CVSS 3.1
8.4/10

CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

VendorProductVersions
LinuxLinux>= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < acb4e26295e7f0e685815a3fd3d70bd8329cefa1; >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < f3859c35a4fbc1c1c58431f684f808e43696891d; >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < f7b5fa83e2c192be922121b764415fa8c7549ea1; >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < b7528b42813f02724a78fce1da24d69d1bfc4d38; >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < 7e32d4eebae6ca24f8a673c107fd7eca1f47afc2; >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < f8288214459ead7e87d26e5822f62c14a4f2ed6b; >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < edaf5b6bd625356893da20d69a259b34a9de2694; >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < 813f8136a2ce1fee266d02a7df73db6e8a541604
LinuxLinux2.6.12

References

Timeline

Published
Last Modified
Status
Received

Frequently Asked Questions

What is CVE-2026-80536?
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.
How severe is CVE-2026-80536?
CVE-2026-80536 has a CVSS score of 8.4/10 (HIGH severity).
How do I fix CVE-2026-80536?
Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

View all 2026CVEs →

Are you affected by CVE-2026-80536?

Run a free Strix scan to check your systems for this vulnerability.

Scan your code now

Source: NVD / NIST