GHSA-qcc7-grh2-48hx: 
In the Linux kernel, the following vulnerability has been resolved:btrfs: fix removed dentries still existing after log is syncedWhen we move one inode from one directory to another and both the inode
and its previous parent directory were logged before, we are not supposed
to have the dentry for the old parent if we have a power failure after the
log is synced. Only the new dentry is supposed to exist.Generally this works correctly, however there is a scenario where this is
not currently working, because the old parent of the file/directory that
was moved is not authoritative for a range that includes the dir index and
dir item keys of the old dentry. This case is better explained with the
following example and reproducer:The test requires a very specific layout of keys and items in thefs/subvolume btree to trigger the bug. So we want to make sure thaton whatever platform we are, we have the same leaf/node size.Currently in btrfs the node/leaf size can not be smaller than the pagesize (but it can be greater than the page size). So use the largestsupported node/leaf size (64K).$ mkfs.btrfs -f -n 65536 /dev/sdc
  $ mount /dev/sdc /mnt"testdir" is inode 257.$ mkdir /mnt/testdir
  $ chmod 755 /mnt/testdirCreate several empty files to have the directory "testdir" with itsitems spread over several leaves (7 in this case).$ for ((i = 1; i <= 1200; i++)); do
       echo -n > /mnt/testdir/file$i
    doneCreate our test directory "dira", inode number 1458, which gets allits items in leaf 7.The BTRFS_DIR_ITEM_KEY item for inode 257 ("testdir") that points tothe entry named "dira" is in leaf 2, while the BTRFS_DIR_INDEX_KEYitem that points to that entry is in leaf 3.For this particular filesystem node size (64K), file count and filenames, we endup with the directory entry items from inode 257 inleaves 2 and 3, as previously mentioned - what matters for triggeringthe bug exercised by this test case is that those items are not placedin leaf 1, they must be placed in a leaf different from the onecontaining the inode item for inode 257.The corresponding BTRFS_DIR_ITEM_KEY and BTRFS_DIR_INDEX_KEY items forthe parent inode (257) are the following:item 460 key (257 DIR_ITEM 3724298081) itemoff 48344 itemsize 34location key (1458 INODE_ITEM 0) type DIRtransid 6 data_len 0 name_len 4name: diraand:item 771 key (257 DIR_INDEX 1202) itemoff 36673 itemsize 34location key (1458 INODE_ITEM 0) type DIRtransid 6 data_len 0 name_len 4name: dira$ mkdir /mnt/testdir/diraMake sure everything done so far is durably persisted.$ syncNow do a change to inode 257 ("testdir") that does not result inCOWing leaves 2 and 3 - the leaves that contain the directory itemspointing to inode 1458 (directory "dira").Changing permissions, the owner/group, updating or adding a xattr,etc, will not change (COW) leaves 2 and 3. So for the sake ofsimplicity change the permissions of inode 257, which results inupdating its inode item and therefore change (COW) only leaf 1.$ chmod 700 /mnt/testdirNow fsync directory inode 257.Since only the first leaf was changed/COWed, we log the inode item ofinode 257 and only the dentries found in the first leaf, all have akey type of BTRFS_DIR_ITEM_KEY, and no keys of typeBTRFS_DIR_INDEX_KEY, because they sort after the former type and noneexist in the first leaf.We also log 3 items that represent ranges for dir items and dirindexes for which the log is authoritative:1) a key of type BTRFS_DIR_LOG_ITEM_KEY, which indicates the log isauthoritative for all BTRFS_DIR_ITEM_KEY keys that have an offsetin the range [0, 2285968570] (the offset here is th---truncated---
CVSS v3.1: 5.5