CVE-2026-64567 in Linux
Summary
by MITRE • 08/05/2026
In the Linux kernel, the following vulnerability has been resolved:
btrfs: reject free space cache with more entries than pages
When loading a v1 free space cache, __load_free_space_cache() takes num_entries and num_bitmaps straight from the on-disk btrfs_free_space_header. That header is stored in the tree_root under a key with type 0, which the tree-checker has no case for, so neither count is validated before the load trusts it.
The load loops num_entries times and maps the next page whenever the current one runs out, going through io_ctl_check_crc() -> io_ctl_map_page(), which does io_ctl->pages[io_ctl->index++]. But pages[] is allocated in
io_ctl_init() from the cache inode's i_size, not from num_entries:
num_pages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); io_ctl->pages = kcalloc(num_pages, sizeof(struct page *), GFP_NOFS);
So if num_entries claims more records than the pages can hold, io_ctl->index runs off the end of pages[]. The write side never hits this because
io_ctl_add_entry() and io_ctl_add_bitmap() both stop once io_ctl->index >= io_ctl->num_pages; the read side just never had the same check.
To trigger it, take a clean cache (num_entries = <N> here), set num_entries in the header to 0x10000, and fix up the leaf checksum so it still passes the tree-checker. The cache inode has i_size = 65536, so num_pages is 16 and pages[] is a 16-pointer (kmalloc-128) array. The load now tries to read
65536 entries, io_ctl->index walks up to 16, and pages[16] is read past the
array:
BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) Read of size 8 at addr ffff88800c833a80 by task kworker/u8:3/58 io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) __load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820) load_free_space_cache (fs/btrfs/free-space-cache.c:1017) caching_thread (fs/btrfs/block-group.c:880) btrfs_work_helper (fs/btrfs/async-thread.c:312) process_one_work worker_thread kthread ret_from_fork
free-space-cache.c:420 is io_ctl_map_page(), inlined into io_ctl_check_crc() at line 565, which is why that is the frame KASAN names. The out-of-bounds slot is then treated as a struct page and handed to crc32c(), so the bad read turns into a GP fault.
Add the missing check to io_ctl_check_crc(), which is where both the entry loop and the bitmap loop end up. When num_entries is too large the load now fails like any corrupt cache: __load_free_space_cache() drops it and rebuilds the free space from the extent tree, so a valid cache is never rejected.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/05/2026
The vulnerability described represents a critical buffer overflow in the Linux kernel's btrfs file system implementation that stems from insufficient validation of free space cache metadata during loading operations. This flaw exists in the free space cache subsystem where the kernel reads on-disk header information without proper bounds checking, leading to potential memory corruption and system instability. The issue specifically affects version 1 free space caches where the number of entries claimed by the cache header exceeds the actual memory allocation for page mapping structures.
The technical root cause lies in the __load_free_space_cache() function which directly trusts the num_entries and num_bitmaps values extracted from the on-disk btrfs_free_space_header structure. This header is stored under a key type 0 in the tree_root, a condition that the existing tree-checker implementation fails to validate properly. The kernel's loading mechanism processes entries in a loop based on the claimed number of entries while mapping pages as needed through io_ctl_check_crc() and io_ctl_map_page() functions, but these operations do not verify that the requested entry count aligns with the allocated page array capacity.
The memory allocation for the page mapping structure occurs independently of the entry count validation, using the cache inode's i_size to determine the number of pages rather than the claimed num_entries value. When a malicious or corrupted cache presents an inflated entry count, specifically when num_entries exceeds the page array size, the io_ctl->index counter continues incrementing beyond valid array bounds, causing out-of-bounds memory access that manifests as a kernel slab-out-of-bounds error. This vulnerability is particularly dangerous because it occurs during normal system operation when attempting to load existing free space cache information, and can result in kernel crashes or potential privilege escalation.
The operational impact of this vulnerability is significant for systems relying on btrfs file systems, as it can cause unexpected system panics or kernel oops conditions during normal file system operations. The flaw allows an attacker with write access to the file system metadata to potentially trigger a denial-of-service condition by crafting malicious cache files with inflated entry counts. Additionally, this vulnerability is classified under CWE-129 Input Validation and CWE-787 Out-of-bounds Write, both of which are critical security weaknesses that can lead to arbitrary code execution or system compromise. The ATT&CK framework would categorize this as a privilege escalation vector through kernel memory corruption techniques, potentially enabling an attacker to gain elevated privileges within the system.
The mitigation strategy involves adding proper bounds checking in the io_ctl_check_crc() function where both entry and bitmap processing loops terminate. This validation ensures that the claimed number of entries does not exceed the allocated page array capacity before proceeding with memory access operations. When such a mismatch is detected, the cache loading process gracefully fails and falls back to rebuilding the free space information from the extent tree, maintaining system stability while preventing the buffer overflow condition. The fix maintains backward compatibility by preserving existing behavior for legitimate caches while properly handling malicious or corrupted inputs that could otherwise lead to kernel memory corruption and system instability.