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
Affected Products
Linux