PT-2026-98050 · Linux · Linux

CVE-2026-97416

·

Published

2026-09-24

·

Updated

2026-09-24

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
btrfs: balance: fix potential bg lookup failure in btrfs may alloc data chunk()
[BUG] Running btrfs balance can trigger a null-ptr-deref before relocating a data chunk when metadata corruption leaves a chunk in the chunk tree without a corresponding block group in the in-memory cache:
KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f] RIP: 0010:btrfs may alloc data chunk+0x40/0x1c0 fs/btrfs/volumes.c:3601 Call Trace: btrfs balance fs/btrfs/volumes.c:4217 [inline] btrfs balance+0x2516/0x42b0 fs/btrfs/volumes.c:4604 btrfs ioctl balance fs/btrfs/ioctl.c:3577 [inline] btrfs ioctl+0x25cf/0x5b90 fs/btrfs/ioctl.c:5313 ...
[CAUSE] btrfs balance() iterates the on-disk chunk tree and passes the chunk logical bytenr to btrfs may alloc data chunk() before relocating a data chunk. That helper then queries the in-memory block group cache:
cache = btrfs lookup block group(fs info, chunk offset); chunk type = cache->flags; /* cache may be NULL */
A corrupt image can contain a chunk item whose matching block group item is missing, so no block group is ever inserted into the cache. In that case btrfs lookup block group() returns NULL.
The code only guards this with ASSERT(cache), which becomes a no-op when CONFIG BTRFS ASSERT is disabled. The subsequent dereference of cache->flags therefore crashes the kernel.
[FIX] Add a NULL check after btrfs lookup block group() in btrfs may alloc data chunk() and print and error message for clarity.
Found an issue in the description? Have something to add? Feel free to write us 👾

Related Identifiers

CVE-2026-97416

Affected Products

Linux