CVE-2023-53618: btrfs: reject invalid reloc tree root keys with stack dump
In the Linux kernel, the following vulnerability has been resolved:
btrfs: reject invalid reloc tree root keys with stack dump
[BUG]
Syzbot reported a crash that an ASSERT() got triggered inside
prepare_to_merge().
That ASSERT() makes sure the reloc tree is properly pointed back by its
subvolume tree.
[CAUSE]
After more debugging output, it turns out we had an invalid reloc tree:
BTRFS error (device loop1): reloc tree mismatch, root 8 has no reloc root, expect reloc root key (-8, 132, 8) gen 17
Note the above root key is (TREE_RELOC_OBJECTID, ROOT_ITEM,
QUOTA_TREE_OBJECTID), meaning it's a reloc tree for quota tree.
But reloc trees can only exist for subvolumes, as for non-subvolume
trees, we just COW the involved tree block, no need to create a reloc
tree since those tree blocks won't be shared with other trees.
Only subvolumes tree can share tree blocks with other trees (thus they
have BTRFS_ROOT_SHAREABLE flag).
Thus this new debug output proves my previous assumption that corrupted
on-disk data can trigger that ASSERT().
[FIX]
Besides the dedicated fix and the graceful exit, also let tree-checker to
check such root keys, to make sure reloc trees can only exist for subvolumes.
Security readout for executives and security teams
Plain-English summary
CVE-2023-53618 is a Linux kernel Btrfs flaw where corrupted filesystem metadata can trigger a kernel assertion and crash path. The public record describes a resolved kernel bug, not a confirmed remote compromise or data theft issue.
Executive priority
Treat as a kernel stability issue with uncertain severity. Prioritize normal kernel patching, with higher urgency for systems processing Btrfs media or filesystem images.
Technical view
Btrfs accepted invalid relocation tree root keys for non-subvolume trees. Syzbot found this could reach an ASSERT() in prepare_to_merge(). The fix rejects invalid reloc tree roots and adds tree-checker validation so reloc trees are limited to subvolumes.
Likely exposure
Exposure is most relevant to Linux systems in the affected kernel ranges that use or mount Btrfs filesystems. The source evidence points to malformed or corrupted on-disk Btrfs data as the trigger.
Exploitation context
The bundle marks KEV as false and provides no cited evidence of active exploitation. The described trigger is corrupted on-disk data discovered by Syzbot, suggesting denial-of-service risk rather than proven remote exploitation.
Researcher notes
The record lacks CVSS, CWE, and exploit details. Analysis should stay anchored to Btrfs relocation-tree validation and the fixed stable commits, not broader Linux compromise assumptions.
Mitigation direction
Check vendor kernel advisories for your distribution's fixed packages.
Prioritize updates on systems that mount Btrfs filesystems.
Avoid mounting untrusted Btrfs images on affected kernels.
Track the referenced stable kernel fixes in patch verification.
Validation and detection
Inventory Linux kernel versions across Btrfs-capable systems.
Identify hosts actively using or mounting Btrfs filesystems.
Confirm installed kernels include vendor fixes for this CVE.
Review crash logs for Btrfs relocation or prepare_to_merge assertion failures.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2023-53618 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
5Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Oct 7, 2025, 15:19 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.