CVE-2026-80536 xfs: bounds-check buffer log item's dirty bitmap

Q: Is CVE-2026-80536 being exploited?

There is no known exploitation of CVE-2026-80536 in the wild and no public exploit code.

High 8.4 Published 26 Aug 2026 Updated 16 Oct 2026

A crafted XFS filesystem image can trigger a heap buffer overflow during log recovery, potentially allowing local attackers to execute code or escalate privileges.

Exploited in the wild: Not known
Login needed: Not needed
Attackable: Local or same network only
Victim action needed: Not needed
Fix: Available

What is CVE-2026-80536?

CVE-2026-80536 is a high-severity memory corruption vulnerability in Linux, published on 26 Aug 2026. It can only be exploited from the same machine or local network, with no action from the victim.

Official 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.

Which versions are affected by CVE-2026-80536?

How do I fix CVE-2026-80536?

Apply the vendor's patch.

Upgrade to the fixed version. Memory-safe languages, compiler hardening and fuzzing prevent most new cases. More about Memory corruption.

Is CVE-2026-80536 being exploited?