CVE-2023-54158 in Linux
Summary
by MITRE • 12/24/2025
In the Linux kernel, the following vulnerability has been resolved:
btrfs: don't free qgroup space unless specified
Boris noticed in his simple quotas testing that he was getting a leak with Sweet Tea's change to subvol create that stopped doing a transaction commit. This was just a side effect of that change.
In the delayed inode code we have an optimization that will free extra reservations if we think we can pack a dir item into an already modified leaf. Previously this wouldn't be triggered in the subvolume create case because we'd commit the transaction, it was still possible but much harder to trigger. It could actually be triggered if we did a mkdir && subvol create with qgroups enabled.
This occurs because in btrfs_insert_delayed_dir_index(), which gets called when we're adding the dir item, we do the following:
btrfs_block_rsv_release(fs_info, trans->block_rsv, bytes, NULL);
if we're able to skip reserving space.
The problem here is that trans->block_rsv points at the temporary block rsv for the subvolume create, which has qgroup reservations in the block rsv.
This is a problem because btrfs_block_rsv_release() will do the following:
if (block_rsv->qgroup_rsv_reserved >= block_rsv->qgroup_rsv_size) {
qgroup_to_release = block_rsv->qgroup_rsv_reserved - block_rsv->qgroup_rsv_size; block_rsv->qgroup_rsv_reserved = block_rsv->qgroup_rsv_size; }
The temporary block rsv just has ->qgroup_rsv_reserved set, ->qgroup_rsv_size == 0. The optimization in btrfs_insert_delayed_dir_index() sets ->qgroup_rsv_reserved = 0. Then later on when we call btrfs_subvolume_release_metadata() which has
btrfs_block_rsv_release(fs_info, rsv, (u64)-1, &qgroup_to_release); btrfs_qgroup_convert_reserved_meta(root, qgroup_to_release);
qgroup_to_release is set to 0, and we do not convert the reserved metadata space.
The problem here is that the block rsv code has been unconditionally messing with ->qgroup_rsv_reserved, because the main place this is used is delalloc, and any time we call btrfs_block_rsv_release() we do it with qgroup_to_release set, and thus do the proper accounting.
The subvolume code is the only other code that uses the qgroup reservation stuff, but it's intermingled with the above optimization, and thus was getting its reservation freed out from underneath it and thus leaking the reserved space.
The solution is to simply not mess with the qgroup reservations if we don't have qgroup_to_release set. This works with the existing code as anything that messes with the delalloc reservations always have qgroup_to_release set. This fixes the leak that Boris was observing.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 01/03/2026
The vulnerability described in CVE-2023-54158 affects the Linux kernel's btrfs file system implementation and represents a qgroup space leak that occurs during subvolume creation operations. This issue stems from an improper interaction between the block reservation system and qgroup accounting mechanisms within the btrfs subsystem. The vulnerability manifests when the delayed inode code attempts to optimize space allocation by freeing extra reservations, but inadvertently interferes with qgroup reservation tracking during subvolume creation processes. The problem specifically occurs in the btrfs_insert_delayed_dir_index() function where block reservation releases are performed without proper qgroup reservation context handling.
The technical flaw involves the manipulation of qgroup reservation values within the block reservation structure during subvolume creation operations. When the temporary block reservation for subvolume creation is processed, the code incorrectly modifies the qgroup_rsv_reserved field even when qgroup_to_release is not properly set. This causes the qgroup reservation system to believe that reserved space has been freed when it actually hasn't, resulting in a memory leak of qgroup space. The issue is exacerbated by the optimization in btrfs_insert_delayed_dir_index() that attempts to pack directory items into existing leaves, which triggers the problematic code path when transaction commits are skipped during subvolume creation. This behavior was previously masked by transaction commit operations but became apparent after changes to subvolume creation that eliminated automatic transaction commits.
The operational impact of this vulnerability extends to storage management and resource accounting within btrfs file systems, particularly affecting systems that utilize qgroup quotas for storage monitoring and allocation. The leak occurs during subvolume creation operations when qgroup reservations are improperly released, leading to incorrect accounting of reserved space that can accumulate over time. This affects systems where multiple subvolumes are created without transaction commits, such as those using the Sweet Tea changes mentioned in the description, and creates potential issues for storage administrators who rely on accurate qgroup reporting for capacity planning and resource allocation. The vulnerability is particularly concerning in environments where precise storage accounting is critical for compliance or resource management purposes.
The mitigation approach involves modifying the block reservation release logic to avoid manipulating qgroup reservations when qgroup_to_release is not properly set. This solution ensures that qgroup reservation accounting only occurs when appropriate context is available, maintaining the existing functionality for delalloc operations while preventing the unintended release of qgroup reservations during subvolume creation. The fix aligns with established practices in kernel development where conditional logic prevents incorrect state modifications and maintains proper resource accounting. This approach follows the principle of least privilege in resource management and prevents the corruption of qgroup reservation state that could lead to storage accounting discrepancies. The solution is backward compatible with existing code paths that properly set qgroup_to_release and maintains all existing functionality while resolving the specific leak scenario identified in the vulnerability description.
This vulnerability maps to CWE-404, which covers improper resource release or unbalanced resource management, and relates to ATT&CK technique T1490, which covers data destruction through resource exhaustion or corruption. The issue demonstrates how seemingly minor optimization changes can create unexpected interactions between different subsystems, highlighting the importance of comprehensive testing for side effects in kernel modifications. The problem also relates to the broader category of resource leak vulnerabilities that can accumulate over time and impact system stability and resource availability. The fix represents a targeted approach to preventing qgroup reservation corruption while maintaining the intended optimization behavior in the btrfs file system's delayed inode handling code.