CVE-2023-54121 in Linux
Summary
by MITRE • 12/24/2025
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix incorrect splitting in btrfs_drop_extent_map_range
In production we were seeing a variety of WARN_ON()'s in the extent_map code, specifically in btrfs_drop_extent_map_range() when we have to call add_extent_mapping() for our second split.
Consider the following extent map layout
PINNED [0 16K) [32K, 48K)
and then we call btrfs_drop_extent_map_range for [0, 36K), with
skip_pinned == true. The initial loop will have
start = 0 end = 36K len = 36K
we will find the [0, 16k) extent, but since we are pinned we will skip
it, which has this code
start = em_end; if (end != (u64)-1) len = start + len - em_end;
em_end here is 16K, so now the values are
start = 16K len = 16K + 36K - 16K = 36K
len should instead be 20K. This is a problem when we find the next extent at [32K, 48K), we need to split this extent to leave [36K, 48k),
however the code for the split looks like this
split->start = start + len; split->len = em_end - (start + len);
In this case we have
em_end = 48K split->start = 16K + 36K // this should be 16K + 20K split->len = 48K - (16K + 36K) // this overflows as 16K + 36K is 52K
and now we have an invalid extent_map in the tree that potentially overlaps other entries in the extent map. Even in the non-overlapping case we will have split->start set improperly, which will cause problems with any block related calculations.
We don't actually need len in this loop, we can simply use end as our end point, and only adjust start up when we find a pinned extent we need to skip.
Adjust the logic to do this, which keeps us from inserting an invalid extent map.
We only skip_pinned in the relocation case, so this is relatively rare, except in the case where you are running relocation a lot, which can happen with auto relocation on.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 01/03/2026
The vulnerability described in CVE-2023-54121 affects the btrfs file system implementation within the Linux kernel, specifically in the btrfs_drop_extent_map_range function. This issue manifests as incorrect splitting behavior when managing extent maps during file system operations. The flaw occurs when processing extent map ranges that contain pinned regions, leading to improper calculation of extent boundaries during split operations. The vulnerability is particularly concerning as it can result in invalid extent map entries that potentially overlap with other entries in the extent map tree, creating data integrity issues and system instability.
The technical root cause lies in the improper handling of length calculations within the btrfs_drop_extent_map_range function when dealing with pinned extents. During the processing loop, when a pinned extent is encountered and skipped, the code incorrectly recalculates the remaining length parameter. Specifically, when processing an extent map with layout [0 16K) and [32K 48K) and attempting to drop range [0 36K) with skip_pinned enabled, the len variable is computed as 36K instead of the correct 20K. This miscalculation propagates through subsequent operations, causing the split logic to compute incorrect start positions for new extent entries. The split operation uses the formula split->start = start + len and split->len = em_end - (start + len), which results in overflow conditions when the incorrect len value of 36K is used.
The operational impact of this vulnerability extends beyond simple calculation errors to potentially compromise file system integrity and system stability. When the extent map becomes corrupted due to incorrect splitting, it can lead to data corruption, file system inconsistencies, and potential system crashes. The vulnerability affects btrfs file systems during operations involving extent map management, particularly when relocation processes are active. The issue is most prevalent in environments where automatic relocation is enabled and frequently executed, creating conditions where the problematic code path is more likely to be triggered. This makes the vulnerability particularly concerning for production systems running btrfs with auto-relocation features enabled, as it can lead to gradual degradation of file system health over time.
Mitigation strategies for CVE-2023-54121 focus on applying the kernel patch that corrects the length calculation logic in the btrfs_drop_extent_map_range function. The fix involves eliminating the problematic len variable usage in the loop and instead relying solely on the end parameter as the endpoint for processing. This change ensures that when pinned extents are encountered and skipped, the start position is properly adjusted without incorrectly modifying the remaining length calculation. Organizations should prioritize applying the relevant kernel updates that contain this fix, particularly those addressing btrfs file system stability issues. System administrators should also monitor for WARN_ON messages related to extent_map operations and consider temporarily disabling auto-relocation features in affected systems until patches are applied. The vulnerability aligns with CWE-129 Input Validation and CWE-691 Insufficient Control Flow Management categories, and represents a control flow management issue that could enable further exploitation through file system corruption attacks. This vulnerability also maps to ATT&CK technique T1490 Inhibit System Recovery, as file system corruption can prevent normal system recovery operations.