CVE-2026-89645
NoneCVSS
—
EPSS
0.2%
Published
Sep 11, 2026
CISA due date
—
Cloudanix analysis
A bug in the Linux storage code can leave behind internal references after a recovery error, which may cause crashes or wasted memory on affected systems.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Memory Corruption
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Improper cleanup of fs_root->reloc_root pointers and associated references during btrfs relocation recovery on error paths (before merge_reloc_roots and clean_dirty_subvols) leaves dangling references when the first transaction commit fails or later roots cannot be processed.
Why it matters to the business
Linux systems using btrfs may experience resource leaks, mount failures, or kernel instability under relocation recovery error conditions, increasing operational risk for storage workloads.
How an attack unfolds
An attacker with local access supplies a btrfs image with pending relocations and forces an error (such as -ENOMEM) during btrfs_recover_relocation to trigger the incomplete reference drop path, potentially leading to memory corruption or denial of service on subsequent operations.
How to fix it
Apply the upstream btrfs fix that maintains temporary fs root references during recovery and clears reloc_root pointers plus drops refs on failure paths; upgrade to a kernel containing the resolution for CVE-2026-89645.
How to confirm the fix worked
Verify the fix by reproducing the original fault-injection scenario and confirming reloc_root reference counts drop to zero on error; inspect kernel source for the updated btrfs_recover_relocation logic and test mount behavior on pending-relocation images.
Typical attack path
- Prepare or obtain a btrfs filesystem image with active relocation state
- Trigger mount or recovery with injected fault causing first-commit failure or root load error
- Observe incomplete cleanup leaving reloc_root references with fs_error unset
- Continue filesystem operations to exploit lingering references for memory corruption
How to detect it
Examine kernel logs for btrfs recovery error paths and mount failures without BTRFS_FS_ERROR; correlate with filesystem images showing pending relocations; no public exploitation artifacts exist.
What your security team should do
- Prioritize kernel updates for any systems running btrfs with relocation enabled
- Monitor for btrfs mount failures or memory pressure on storage servers
- Apply defense-in-depth by restricting untrusted btrfs image handling
- Review EPSS and exploit maturity data; no active threat actor campaigns reported
The record
In the Linux kernel, the following vulnerability has been resolved: btrfs: drop recovered reloc root refs on recovery failure During relocation recovery, each fs root gets a reference to its relocation root. If loading or adding a later root fails, or if the first transaction commit fails, btrfs_recover_relocation() jumps to out_unset before merge_reloc_roots() and clean_dirty_subvols(). put_reloc_control() drops the list-owned relocation root references, but it does not clear fs_root->reloc_root or drop the references owned by those pointers. Mount cleanup only drops them when BTRFS_FS_ERROR is set, so an error such as -ENOMEM while processing a later root can leave references behind. Keep temporary references to the fs roots associated during recovery. On failure, clear their reloc_root pointers and drop the corresponding references. Once the first transaction commit succeeds, drop only the temporary fs root references and let the normal merge and cleanup paths handle the relocation roots. Fault injection on a pending-relocation image confirmed the cleanup gap. With an injected first-commit failure, 25 fs roots had reloc_root set with fs_error=0. With this fix, the same failure path drops that count to 0 before mount fails.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|