CVE-2026-99067

What it actually does

Reference leak to a btrfs root object occurs in scrub_print_warning_inode when paths_from_inode fails, because the reference acquired by btrfs_get_fs_root is not released on that error path while every other path does release it.

Why it matters to the business

Repeated scrub operations that encounter path-resolution failures can slowly exhaust kernel memory on btrfs file systems, potentially leading to instability or crashes in long-running storage servers.

How an attack unfolds

An attacker with local access triggers btrfs scrub operations that produce warnings and cause paths_from_inode to fail, repeatedly leaking references until memory pressure or an out-of-memory condition occurs.

How to fix it

Apply the upstream kernel commit that adds the missing btrfs_put_fs_root call on the paths_from_inode failure path; rebuild and boot the fixed kernel on all affected btrfs systems.

How to confirm the fix worked

Confirm the btrfs scrub code path now releases the root reference in every error and success case by code review or by running targeted scrub workloads that previously triggered the leak and monitoring for reference-count growth.

Typical attack path

1. Obtain local access on a system using btrfs
2. Induce scrub warning conditions that exercise the paths_from_inode failure path
3. Repeat to accumulate leaked root references
4. Observe memory exhaustion or system instability

How to detect it

Examine kernel memory statistics and reference-count traces during scrub operations; look for btrfs root objects whose reference counts grow without corresponding decrements after scrub warning paths are exercised.

What your security team should do

• Prioritize kernel update on any production btrfs deployments within the next maintenance window
• Monitor kernel memory usage and OOM events on btrfs hosts until patched
• Review internal change-management process for rapid adoption of low-severity kernel fixes