Linux Kernel up to 5.15.126/6.1.45/6.4.10 btrfs assertion

Summaryinfo

A vulnerability was found in Linux Kernel up to 5.15.126/6.1.45/6.4.10. It has been classified as critical. The affected element is an unknown function of the component btrfs. Performing a manipulation results in assertion. This vulnerability is known as CVE-2023-53618. No exploit is available. Upgrading the affected component is recommended.

Detailsinfo

A vulnerability classified as critical has been found in Linux Kernel up to 5.15.126/6.1.45/6.4.10. This affects an unknown code block of the component btrfs. The manipulation with an unknown input leads to a assertion vulnerability. CWE is classifying the issue as CWE-617. The product contains an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary. This is going to have an impact on availability. The summary by CVE is:

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.

The advisory is shared at git.kernel.org. This vulnerability is uniquely identified as CVE-2023-53618 since 10/07/2025. The exploitability is told to be difficult. Neither technical details nor an exploit are publicly available.

Upgrading to version 5.15.127, 6.1.46 or 6.4.11 eliminates this vulnerability. Applying the patch 314135b7bae9618a317874ae195272682cf2d5d4/3ae93b316ca4b8b3c33798ef1d210355f2fb9318/84256e00eeca73c529fc6196e478cc89b8098157/6ebcd021c92b8e4b904552e4d87283032100796d is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

The vulnerability is also documented in the vulnerability database at CERT Bund (WID-SEC-2025-2229). Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Affected

• Debian Linux
• Amazon Linux 2
• Red Hat Enterprise Linux
• Ubuntu Linux
• SUSE Linux
• Oracle Linux
• RESF Rocky Linux
• Open Source Linux Kernel
• IBM QRadar SIEM
• Dell NetWorker

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 5.15.126
• 6.1.0
• 6.1.1
• 6.1.2
• 6.1.3
• 6.1.4
• 6.1.5
• 6.1.6
• 6.1.7
• 6.1.8
• 6.1.9
• 6.1.10
• 6.1.11
• 6.1.12
• 6.1.13
• 6.1.14
• 6.1.15
• 6.1.16
• 6.1.17
• 6.1.18
• 6.1.19
• 6.1.20
• 6.1.21
• 6.1.22
• 6.1.23
• 6.1.24
• 6.1.25
• 6.1.26
• 6.1.27
• 6.1.28
• 6.1.29
• 6.1.30
• 6.1.31
• 6.1.32
• 6.1.33
• 6.1.34
• 6.1.35
• 6.1.36
• 6.1.37
• 6.1.38
• 6.1.39
• 6.1.40
• 6.1.41
• 6.1.42
• 6.1.43
• 6.1.44
• 6.1.45
• 6.4.0
• 6.4.1
• 6.4.2
• 6.4.3
• 6.4.4
• 6.4.5
• 6.4.6
• 6.4.7
• 6.4.8
• 6.4.9
• 6.4.10

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discussion