CVE-2023-54158
Unknown Unknown - Not Provided
Memory Leak in Linux Kernel btrfs Qgroup Reservation Handling

Publication date: 2025-12-24

Last updated on: 2025-12-24

Assigner: kernel.org

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-12-24
Last Modified
2025-12-24
Generated
2026-05-07
AI Q&A
2025-12-25
EPSS Evaluated
2026-05-05
NVD
CVE-2023-54158
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, update the Linux kernel to a version where the btrfs qgroup space leak issue has been fixed. The fix involves ensuring that qgroup reservations are not freed improperly during subvolume creation. Applying the latest kernel patches or updates that address this specific btrfs issue will prevent the reserved space leak.


Can you explain this vulnerability to me?

This vulnerability in the Linux kernel's btrfs filesystem involves improper handling of quota group (qgroup) space reservations during subvolume creation. Specifically, an optimization in the delayed inode code incorrectly frees qgroup reserved space when it shouldn't, due to how temporary block reservations are managed. This leads to a leak of reserved space because the qgroup reservations are freed prematurely and not properly accounted for, causing reserved metadata space to be lost.


How can this vulnerability impact me? :

The vulnerability can cause a leak of reserved quota group space in the btrfs filesystem during subvolume creation. This means that disk space reserved for quota management may be lost or not properly tracked, potentially leading to inaccurate quota enforcement and inefficient disk space usage.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart