CVE-2026-68450 Overview
CVE-2026-68450 is a memory leak vulnerability in the Linux kernel's Btrfs filesystem. The flaw resides in the __add_reloc_root() function, which allocates a mapping_node before inserting it into rc->reloc_root_tree. When rb_simple_insert() detects a duplicate entry, it returns the existing red-black tree node and leaves the newly allocated node unlinked. The error path then returns -EEXIST without freeing the orphaned allocation.
Critical Impact
The unlinked mapping_node cannot be reclaimed by put_reloc_control() cleanup, causing a kernel memory leak on the duplicate reloc root insert path in Btrfs.
Affected Products
- Linux kernel Btrfs filesystem subsystem
- Multiple stable kernel branches referenced in upstream commits
- Systems running Btrfs with relocation operations (balance, device replace)
Discovery Timeline
- 2026-08-12 - CVE-2026-68450 published to NVD
- 2026-08-12 - Last updated in NVD database
Technical Details for CVE-2026-68450
Vulnerability Analysis
The vulnerability exists in the Btrfs relocation code path within the Linux kernel. The __add_reloc_root() function creates a mapping_node structure and attempts to add it to the relocation control's reloc_root_tree red-black tree. The insertion is performed via rb_simple_insert(), which follows standard red-black tree semantics: if a node with the same key already exists, it returns the pre-existing node rather than inserting the caller's new node.
The function's error handling checks whether the returned node differs from the newly allocated one, and returns -EEXIST if a duplicate exists. However, the error path returns without invoking kfree() on the freshly allocated mapping_node. Because the node was never linked into reloc_root_tree, the subsequent cleanup performed by put_reloc_control() cannot walk to it, and the allocation is permanently orphaned.
Root Cause
The root cause is missing cleanup on an error path following a failed red-black tree insertion. This is a classic memory leak pattern where an allocation succeeds but the object never becomes reachable through any tracked data structure. Upstream maintainers note that callers currently assert -EEXIST should not occur, making this a defensive fix. If the duplicate path is ever triggered, the local allocation must still be released.
Attack Vector
The vulnerability requires the duplicate reloc root insert code path to execute, which the existing callers treat as an unexpected condition. Local access to a Btrfs filesystem performing relocation operations, such as balance or device replace, would be needed to potentially trigger the path. No remote attack vector or verified proof of concept is available. The primary impact is gradual kernel memory exhaustion in edge cases.
See the upstream fix in the kernel.org commit log for the specific patch that adds the missing kfree() call before returning -EEXIST.
Detection Methods for CVE-2026-68450
Indicators of Compromise
- Unexplained growth in kernel slab allocations attributable to Btrfs mapping_node objects
- Repeated Btrfs relocation failures reporting -EEXIST in dmesg or journalctl -k output
- Progressive reduction in available kernel memory on hosts running frequent Btrfs balance or device replace operations
Detection Strategies
- Monitor /proc/slabinfo for anomalous growth in Btrfs-related slab caches over time
- Enable CONFIG_DEBUG_KMEMLEAK on test kernels to identify unfreed allocations from __add_reloc_root()
- Correlate kernel version and patch level against the fixing commits listed in the upstream references
Monitoring Recommendations
- Track kernel memory metrics on Btrfs-heavy workloads such as storage servers and container hosts
- Alert on Btrfs balance or relocation operations that terminate with unexpected error codes
- Include kernel version inventory in configuration management to identify unpatched hosts running vulnerable Btrfs code
How to Mitigate CVE-2026-68450
Immediate Actions Required
- Apply the upstream Btrfs patch that frees the newly allocated mapping_node before returning -EEXIST
- Update to a kernel release that includes the fix from the referenced stable tree commits
- Inventory all Linux hosts using Btrfs as a primary filesystem to prioritize patching
Patch Information
The fix has been merged into multiple stable kernel branches. The relevant commits are available at kernel.org commit 797dc567, kernel.org commit 14a8be94, kernel.org commit 6a8269b6, kernel.org commit 92bedc04, and kernel.org commit ae0629ff. Distribution vendors have backported the change to their supported kernel packages.
Workarounds
- Reduce the frequency of Btrfs balance and device replace operations on unpatched systems to lower the probability of hitting the code path
- Schedule periodic reboots on long-running Btrfs hosts until patched kernels are deployed to clear any accumulated leaked memory
- Consider migrating critical workloads to patched kernel builds provided by your Linux distribution vendor
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
