CVE-2026-89644 in Linux
Summary
by MITRE • 09/12/2026
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix extent map leak in NOCOW direct I/O write
btrfs_dio_iomap_begin() calls btrfs_get_extent(), which returns an extent map reference that must be dropped on all exit paths.
For direct writes into a NOCOW range, btrfs_get_blocks_direct_write() keeps using that extent map and asks btrfs_create_dio_extent() to allocate the ordered extent. If that fails, for example because btrfs_alloc_ordered_extent() fails, the function returns the error without dropping the input extent map. The PREALLOC path avoided this by dropping the input extent map before replacing it with the newly created one.
Check the error from btrfs_create_dio_extent() before replacing the map and drop the input extent map on failure.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/12/2026
The Linux kernel's Btrfs filesystem implementation contains a resource management flaw within its direct I/O write path for files configured with the NOCOW, or Copy-On-Write disabled, attribute. This vulnerability manifests specifically when handling direct writes where the underlying storage allocation fails during the creation of an ordered extent structure. The core issue resides in the function btrfs_dio_iomap_begin, which invokes btrfs_get_extent to retrieve a reference to an existing extent map representing the file's data layout on disk. According to standard kernel memory management practices and Btrfs internal protocols, any reference obtained through such getter functions must be explicitly released or dropped by the caller once it is no longer needed to prevent resource exhaustion. In normal operation paths where allocation succeeds, this cleanup occurs correctly; however, in error scenarios involving direct writes to NOCOW ranges, a critical path was overlooked during code review and implementation phases.
The technical flaw occurs within btrfs_get_blocks_direct_write when the system attempts to allocate an ordered extent via btrfs_create_dio_extent. This function is responsible for setting up metadata structures that track pending write operations before they are committed to disk. If this allocation fails, typically due to memory pressure or insufficient space on the storage device, the error handling logic returns immediately without releasing the previously acquired extent map reference from btrfs_get_extent. While other code paths within Btrfs, such as those involving PREALLOC strategies, correctly drop the input extent map before attempting replacement with newly created structures, this specific direct I/O path lacks that safeguard. Consequently, every failed write attempt results in a leaked kernel memory object of type struct btrfs_extents_map. Although individual leaks are small, they accumulate rapidly under sustained load or repeated failure conditions, leading to significant resource depletion within the kernel space.
The operational impact of this vulnerability is primarily characterized by progressive kernel memory leakage and potential system instability over time. As the number of failed direct I/O operations increases, the untracked extent maps consume contiguous blocks of non-swapable kernel memory. This gradual consumption can lead to increased pressure on the kernel's page allocator, potentially triggering out-of-memory conditions even when physical RAM appears available but is fragmented or reserved for other critical subsystems. In severe cases, this resource exhaustion may cause processes waiting for I/O operations to hang indefinitely, degrade overall system performance due to excessive swapping of kernel memory pages, or result in a complete kernel panic if the allocation failures become frequent enough to destabilize core data structures. For systems running database servers or high-throughput storage applications that rely heavily on direct I/O and NOCOW semantics for performance optimization, this vulnerability poses a tangible risk to availability and reliability.
From a classification perspective, this issue aligns with CWE-401, which describes the improper release of memory or resources before exiting or returning from a function, often referred to as a resource leak. It also relates to CWE-772, concerning missing release of resources after effective ownership, highlighting the failure in lifecycle management of kernel objects. In terms of adversarial tactics, while this is not directly exploitable for remote code execution, it facilitates Denial of Service scenarios consistent with ATT&CK technique T1496, Resource Hijacking, where an attacker or misconfigured workload can degrade system availability by exhausting computational resources such as memory. The vulnerability underscores the importance of rigorous error path validation in complex filesystem drivers where multiple layers of abstraction manage shared state and references.
Mitigation strategies for this issue involve applying the specific patch provided by the Linux kernel maintainers that addresses btrfs_dio_iomap_begin to ensure proper reference counting on all exit paths. System administrators should prioritize updating their kernels to versions containing this fix, particularly if they utilize Btrfs with NOCOW settings and experience frequent direct I/O failures due to storage constraints or hardware issues. Until patches are applied, monitoring kernel memory usage for anomalies related to btrfs extent maps can help identify affected systems early. Additionally, ensuring adequate free space on the underlying block devices reduces the likelihood of triggering the allocation failure that exposes this code path. Long-term remediation includes enforcing static analysis tools and rigorous code review processes focused on reference counting integrity in filesystem drivers to prevent similar resource management errors from being introduced into other parts of the kernel storage stack.