CVE-2023-53618

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: reject invalid reloc tree root keys with stack dump<br /> <br /> [BUG]<br /> Syzbot reported a crash that an ASSERT() got triggered inside<br /> prepare_to_merge().<br /> <br /> That ASSERT() makes sure the reloc tree is properly pointed back by its<br /> subvolume tree.<br /> <br /> [CAUSE]<br /> After more debugging output, it turns out we had an invalid reloc tree:<br /> <br /> BTRFS error (device loop1): reloc tree mismatch, root 8 has no reloc root, expect reloc root key (-8, 132, 8) gen 17<br /> <br /> Note the above root key is (TREE_RELOC_OBJECTID, ROOT_ITEM,<br /> QUOTA_TREE_OBJECTID), meaning it&amp;#39;s a reloc tree for quota tree.<br /> <br /> But reloc trees can only exist for subvolumes, as for non-subvolume<br /> trees, we just COW the involved tree block, no need to create a reloc<br /> tree since those tree blocks won&amp;#39;t be shared with other trees.<br /> <br /> Only subvolumes tree can share tree blocks with other trees (thus they<br /> have BTRFS_ROOT_SHAREABLE flag).<br /> <br /> Thus this new debug output proves my previous assumption that corrupted<br /> on-disk data can trigger that ASSERT().<br /> <br /> [FIX]<br /> Besides the dedicated fix and the graceful exit, also let tree-checker to<br /> check such root keys, to make sure reloc trees can only exist for subvolumes.