CVE-2026-64567: btrfs: reject free space cache with more entries than pages

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, loadfreespacecache() takes numentries and numbitmaps straight from the on-disk btrfsfreespaceheader. That header is stored in the treeroot 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 numentries times and maps the next page whenever the current one runs out, going through ioctlcheckcrc() -> ioctlmappage(), which does ioctl->pages[ioctl->index++]. But pages[] is allocated in ioctlinit() from the cache inode's isize, not from numentries:

numpages = DIVROUNDUP(isizeread(inode), PAGESIZE); ioctl->pages = kcalloc(numpages, sizeof(struct page ), GFPNOFS);

So if numentries claims more records than the pages can hold, ioctl->index runs off the end of pages[]. The write side never hits this because ioctladdentry() and ioctladdbitmap() both stop once ioctl->index >= ioctl->numpages; the read side just never had the same check.

To trigger it, take a clean cache (numentries = <N> here), set numentries in the header to 0x10000, and fix up the leaf checksum so it still passes the tree-checker. The cache inode has isize = 65536, so numpages is 16 and pages[] is a 16-pointer (kmalloc-128) array. The load now tries to read 65536 entries, ioctl->index walks up to 16, and pages[16] is read past the array:

BUG: KASAN: slab-out-of-bounds in ioctlcheckcrc (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 ioctlcheckcrc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) loadfreespacecache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820) loadfreespacecache (fs/btrfs/free-space-cache.c:1017) cachingthread (fs/btrfs/block-group.c:880) btrfsworkhelper (fs/btrfs/async-thread.c:312) processonework workerthread kthread retfromfork

free-space-cache.c:420 is ioctlmappage(), inlined into ioctlcheckcrc() 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 ioctlcheckcrc(), which is where both the entry loop and the bitmap loop end up. When numentries is too large the load now fails like any corrupt cache: loadfreespacecache() drops it and rebuilds the free space from the extent tree, so a valid cache is never rejected.