CVE-2026-43393

What it actually does

A chunk map reference obtained via btrfs_chunk_map_lookup is not released on the early -EINVAL return path inside btrfs_map_block after a call to btrfs_chunk_map_num_copies, producing a kernel memory leak.

Why it matters to the business

Sustained local btrfs operations on affected kernels gradually consume kernel memory, risking eventual resource exhaustion, degraded performance, or denial of service on Linux systems that use the btrfs filesystem.

How an attack unfolds

A local attacker repeatedly triggers btrfs_map_block with parameters that cause an early -EINVAL return after the chunk map has already been looked up, accumulating unreleased kernel memory over time.

How to fix it

Apply the upstream btrfs fix that releases the chunk map before returning -EINVAL from btrfs_map_block; rebuild and deploy updated kernel packages for all affected distributions.

How to confirm the fix worked

Inspect the btrfs/super.c and btrfs/volumes.c sources around btrfs_map_block to confirm the chunk map is freed on every return path; run targeted btrfs stress tests while monitoring slab or kmemleak output.

Typical attack path

1. Obtain local unprivileged access on a Linux host using btrfs
2. Perform filesystem operations that exercise btrfs_map_block with conditions leading to the early error return
3. Repeat the operations to accelerate the memory leak

How to detect it

Review kernel logs and slab allocator statistics for repeated btrfs chunk-map allocations without matching frees; enable kmemleak or similar kernel debugging to surface unreleased objects after btrfs activity.

What your security team should do

• Prioritize kernel updates on any systems exposing btrfs volumes to untrusted local users
• Monitor kernel memory statistics for anomalous growth correlated with btrfs activity
• Restrict unprivileged local access on high-value btrfs hosts until patches are applied