CVE-2026-93798: btrfs: fix reloc root cleanup in merge_reloc_roots()
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix reloc root cleanup in mergerelocroots()
If the root we got has zero root refs in its root item, we are resetting the root's ->relocroot without using barriers like we do everywhere else. Sashiko complained about this while reviewing another patch, and it's correct (see the Link tag below).
Also, we should not clear BTRFSROOTDEADRELOCTREE from the root unless the root points to the reloc root we have.
Fix this by using clearrelocroot(), which issues the memory barrier after setting the root's ->relocroot to NULL and before clearing the bit BTRFSROOTDEADRELOCTREE from the root.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In btrfs merge_reloc_roots() cleanup, use clear_reloc_root() instead of clearing BTRFS_ROOT_DEAD_RELOC_TREE directly, so the required memory barrier is issued after setting the root's ->reloc_root to NULL and before clearing the bit.
Event History
Frequently Asked Questions
What runtime condition reaches the affected cleanup path?
The issue occurs when merge_reloc_roots() obtains a root whose root item has zero root references. The affected logic handles that root's relocation-root cleanup.
What does the corrected cleanup sequence do differently?
It uses clear_reloc_root() to set the root's reloc_root pointer to NULL, issue a memory barrier, and then clear BTRFS_ROOT_DEAD_RELOC_TREE. The flag is cleared only when the root points to the relocation root being processed.
How can maintainers check whether their kernel source includes the fix?
Check whether the relevant merge_reloc_roots() cleanup uses clear_reloc_root() rather than directly resetting reloc_root and clearing BTRFS_ROOT_DEAD_RELOC_TREE. The listed stable references identify commits containing the correction.