CVE-2023-52897 in Linux
Summary
by MITRE • 08/21/2024
In the Linux kernel, the following vulnerability has been resolved:
btrfs: qgroup: do not warn on record without old_roots populated
[BUG]
There are some reports from the mailing list that since v6.1 kernel, the WARN_ON() inside btrfs_qgroup_account_extent() gets triggered during rescan:
WARNING: CPU: 3 PID: 6424 at fs/btrfs/qgroup.c:2756 btrfs_qgroup_account_extents+0x1ae/0x260 [btrfs]
CPU: 3 PID: 6424 Comm: snapperd Tainted: P OE 6.1.2-1-default #1 openSUSE Tumbleweed 05c7a1b1b61d5627475528f71f50444637b5aad7 RIP: 0010:btrfs_qgroup_account_extents+0x1ae/0x260 [btrfs]
Call Trace: btrfs_commit_transaction+0x30c/0xb40 [btrfs c39c9c546c241c593f03bd6d5f39ea1b676250f6]
? start_transaction+0xc3/0x5b0 [btrfs c39c9c546c241c593f03bd6d5f39ea1b676250f6]
btrfs_qgroup_rescan+0x42/0xc0 [btrfs c39c9c546c241c593f03bd6d5f39ea1b676250f6]
btrfs_ioctl+0x1ab9/0x25c0 [btrfs c39c9c546c241c593f03bd6d5f39ea1b676250f6]
? __rseq_handle_notify_resume+0xa9/0x4a0 ? mntput_no_expire+0x4a/0x240 ? __seccomp_filter+0x319/0x4d0 __x64_sys_ioctl+0x90/0xd0 do_syscall_64+0x5b/0x80 ? syscall_exit_to_user_mode+0x17/0x40 ? do_syscall_64+0x67/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fd9b790d9bf
[CAUSE]
Since commit e15e9f43c7ca ("btrfs: introduce BTRFS_QGROUP_RUNTIME_FLAG_NO_ACCOUNTING to skip qgroup accounting"), if our qgroup is already in inconsistent state, we will no longer do the time-consuming backref walk.
This can leave some qgroup records without a valid old_roots ulist. Normally this is fine, as btrfs_qgroup_account_extents() would also skip those records if we have NO_ACCOUNTING flag set.
But there is a small window, if we have NO_ACCOUNTING flag set, and inserted some qgroup_record without a old_roots ulist, but then the user triggered a qgroup rescan.
During btrfs_qgroup_rescan(), we firstly clear NO_ACCOUNTING flag, then commit current transaction.
And since we have a qgroup_record with old_roots = NULL, we trigger the WARN_ON() during btrfs_qgroup_account_extents().
[FIX]
Unfortunately due to the introduction of NO_ACCOUNTING flag, the assumption that every qgroup_record would have its old_roots populated is no longer correct.
Fix the false alerts and drop the WARN_ON().
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 02/17/2026
The vulnerability CVE-2023-52897 affects the Linux kernel's btrfs file system implementation and specifically targets the qgroup accounting subsystem. This issue emerged in kernel versions 6.1 and later, where a warning mechanism intended to detect inconsistent qgroup states is being incorrectly triggered during qgroup rescan operations. The warning manifests as a WARN_ON() call within the btrfs_qgroup_account_extent() function, which occurs when the system attempts to process qgroup records that lack properly populated old_roots ulist structures. This condition typically surfaces during rescan operations initiated by tools such as snapperd, creating operational disruptions in systems relying on btrfs qgroup management.
The technical root cause stems from a design change introduced in commit e15e9f43c7ca that implemented the BTRFS_QGROUP_RUNTIME_FLAG_NO_ACCOUNTING flag to skip time-consuming backref walks when qgroup states are already inconsistent. This optimization approach allows the system to avoid expensive operations when qgroup accounting is deemed unreliable, but it creates a scenario where qgroup records may be left without valid old_roots ulist entries. The vulnerability occurs during a specific temporal window where qgroup records are inserted without proper old_roots population while the NO_ACCOUNTING flag is active, but later when a user triggers a qgroup rescan, the system attempts to process these records and encounters the previously assumed invariant that all qgroup records should have populated old_roots structures.
The operational impact of this vulnerability manifests as system warnings that can cause confusion during qgroup rescan operations, potentially leading to false positive alerts that may mislead administrators about actual system inconsistencies. While the warning itself does not cause system crashes or data corruption, it creates noise in system logs that could obscure legitimate issues and may interfere with automated monitoring systems. The vulnerability affects systems running kernel versions 6.1 and later where btrfs qgroup functionality is utilized, particularly in environments using snapshot management tools like snapper that perform regular qgroup rescans. The issue represents a classic case of false positive detection where the warning mechanism was designed to catch genuine inconsistencies but now incorrectly flags valid operational states resulting from legitimate optimization strategies.
The fix for CVE-2023-52897 involves removing the WARN_ON() call that was incorrectly triggering during legitimate operational scenarios. This remediation acknowledges that the assumption about all qgroup records having populated old_roots structures is no longer valid due to the introduction of the NO_ACCOUNTING flag optimization. The solution aligns with the principle that warning mechanisms should not generate false positives in normal operational conditions, which is consistent with security best practices outlined in the CWE-704 category regarding improper warning handling. This vulnerability demonstrates the complexity of maintaining warning systems in optimized code paths where legitimate operational states may not meet the assumptions underlying defensive programming checks, and it highlights the importance of considering all possible code execution paths when introducing optimization features that alter system invariants. The fix ensures that the qgroup accounting subsystem operates correctly without generating spurious warnings while maintaining the intended performance optimizations introduced by the NO_ACCOUNTING flag implementation.