CVE-2022-48833 in Linux
Summary
by MITRE • 07/16/2024
In the Linux kernel, the following vulnerability has been resolved:
btrfs: skip reserved bytes warning on unmount after log cleanup failure
After the recent changes made by commit c2e39305299f01 ("btrfs: clear extent buffer uptodate when we fail to write it") and its followup fix, commit 651740a5024117 ("btrfs: check WRITE_ERR when trying to read an extent buffer"), we can now end up not cleaning up space reservations of log tree extent buffers after a transaction abort happens, as well as not cleaning up still dirty extent buffers.
This happens because if writeback for a log tree extent buffer failed, then we have cleared the bit EXTENT_BUFFER_UPTODATE from the extent buffer and we have also set the bit EXTENT_BUFFER_WRITE_ERR on it. Later on, when trying to free the log tree with free_log_tree(), which iterates over the tree, we can end up getting an -EIO error when trying to read a node or a leaf, since read_extent_buffer_pages() returns -EIO if an extent buffer does not have EXTENT_BUFFER_UPTODATE set and has the EXTENT_BUFFER_WRITE_ERR bit set. Getting that -EIO means that we return immediately as we can not iterate over the entire tree.
In that case we never update the reserved space for an extent buffer in the respective block group and space_info object.
When this happens we get the following traces when unmounting the fs:
[174957.284509] BTRFS: error (device dm-0) in cleanup_transaction:1913: errno=-5 IO failure
[174957.286497] BTRFS: error (device dm-0) in free_log_tree:3420: errno=-5 IO failure
[174957.399379] ------------[ cut here ]------------
[174957.402497] WARNING: CPU: 2 PID: 3206883 at fs/btrfs/block-group.c:127 btrfs_put_block_group+0x77/0xb0 [btrfs]
[174957.407523] Modules linked in: btrfs overlay dm_zero (...)
[174957.424917] CPU: 2 PID: 3206883 Comm: umount Tainted: G W 5.16.0-rc5-btrfs-next-109 #1
[174957.426689] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[174957.428716] RIP: 0010:btrfs_put_block_group+0x77/0xb0 [btrfs]
[174957.429717] Code: 21 48 8b bd (...)
[174957.432867] RSP: 0018:ffffb70d41cffdd0 EFLAGS: 00010206
[174957.433632] RAX: 0000000000000001 RBX: ffff8b09c3848000 RCX: ffff8b0758edd1c8
[174957.434689] RDX: 0000000000000001 RSI: ffffffffc0b467e7 RDI: ffff8b0758edd000
[174957.436068] RBP: ffff8b0758edd000 R08: 0000000000000000 R09: 0000000000000000
[174957.437114] R10: 0000000000000246 R11: 0000000000000000 R12: ffff8b09c3848148
[174957.438140] R13: ffff8b09c3848198 R14: ffff8b0758edd188 R15: dead000000000100
[174957.439317] FS: 00007f328fb82800(0000) GS:ffff8b0a2d200000(0000) knlGS:0000000000000000
[174957.440402] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[174957.441164] CR2: 00007fff13563e98 CR3: 0000000404f4e005 CR4: 0000000000370ee0
[174957.442117] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[174957.443076] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[174957.443948] Call Trace:
[174957.444264]
[174957.444538] btrfs_free_block_groups+0x255/0x3c0 [btrfs]
[174957.445238] close_ctree+0x301/0x357 [btrfs]
[174957.445803] ? call_rcu+0x16c/0x290
[174957.446250] generic_shutdown_super+0x74/0x120
[174957.446832] kill_anon_super+0x14/0x30
[174957.447305] btrfs_kill_super+0x12/0x20 [btrfs]
[174957.447890] deactivate_locked_super+0x31/0xa0
[174957.448440] cleanup_mnt+0x147/0x1c0
[174957.448888] task_work_run+0x5c/0xa0
[174957.449336] exit_to_user_mode_prepare+0x1e5/0x1f0
[174957.449934] syscall_exit_to_user_mode+0x16/0x40
[174957.450512] do_syscall_64+0x48/0xc0
[174957.450980] entry_SYSCALL_64_after_hwframe+0x44/0xae
[174957.451605] RIP: 0033:0x7f328fdc4a97
[174957.452059] Code: 03 0c 00 f7 (...)
[174957.454320] RSP: 002b:00007fff13564ec8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6
[174957.455262] RAX: 0000000000000000 RBX: 00007f328feea264 RCX: 00007f328fdc4a97
[174957.456131] RDX: 0000000000000000 RSI: 00000000000000
---truncated---
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/07/2025
The vulnerability described in CVE-2022-48833 resides within the btrfs file system implementation of the Linux kernel and represents a critical issue related to improper handling of space reservations during transaction aborts. This flaw manifests when the system encounters failures during writeback operations of log tree extent buffers, leading to inconsistent state management and potential resource leaks. The vulnerability stems from changes introduced in commits c2e39305299f01 and 651740a5024117, which altered how extent buffer uptodate flags and write error bits are managed during I/O operations. When a writeback failure occurs, the system clears the EXTENT_BUFFER_UPTODATE flag and sets the EXTENT_BUFFER_WRITE_ERR flag, but this process fails to properly clean up space reservations for affected extent buffers.
The operational impact of this vulnerability becomes apparent during filesystem unmount operations, where the system attempts to clean up transaction logs through the free_log_tree() function. When this cleanup process encounters extent buffers with cleared uptodate flags and set write error flags, the read_extent_buffer_pages() function returns -EIO errors, causing the iteration process to terminate prematurely. This premature termination prevents the system from updating reserved space information in the respective block group and space_info objects, leading to a buildup of unaccounted space reservations. The resulting inconsistency can cause the btrfs_put_block_group() function to trigger kernel warnings and potential system instability during the unmount process.
This vulnerability directly relates to CWE-129 and CWE-131 in the Common Weakness Enumeration catalog, specifically addressing issues with improper handling of buffer boundaries and memory management during I/O operations. The flaw aligns with ATT&CK technique T1490, which involves data destruction through filesystem corruption, and T1566, which covers initial access via exploitation of kernel vulnerabilities. The vulnerability demonstrates a classic case of resource leak and state management failure in a critical subsystem, where the failure to properly clean up after I/O errors leads to inconsistent filesystem state. The issue is particularly concerning because it affects the core filesystem cleanup mechanisms, potentially leading to unmount failures and data accessibility problems. The system behavior shows that the kernel's error handling mechanism fails to account for the specific case where I/O errors during log cleanup prevent proper resource accounting, creating a scenario where space reservations remain marked as active even though the underlying resources are no longer properly managed.
Mitigation strategies for this vulnerability include applying the upstream kernel patches that address the specific commit changes causing the issue, ensuring proper cleanup of space reservations even when I/O errors occur during transaction aborts. System administrators should prioritize updating to kernel versions containing the fix, as the vulnerability can lead to complete filesystem unmount failures and potential data loss scenarios. Additionally, monitoring for the specific error patterns described in the vulnerability report, particularly the combination of IO failure errors during cleanup_transaction and free_log_tree operations, can help identify systems at risk. The fix implemented in the kernel ensures that even when extent buffer read operations fail due to I/O errors, the system continues to properly account for and release space reservations, maintaining filesystem consistency and preventing resource leaks that could lead to system instability during unmount operations.