In the Linux kernel, a vulnerability has been discovered and resolved in Btrfs, a popular copy-on-write filesystem for the Linux operating system. The security vulnerability, identified as CVE-2021-47072, involves a situation when removed dentries may still exist after the log is synced. This issue arises due to a specific case where the old parent of a moved file/directory is not authoritative for a range that includes the dir index and dir item keys of the old dentry.

The problem can be better understood and replicated using the following code snippets and reproduction steps. Note that the test requires a specific layout of keys and items in the filesystem/subvolume btree to trigger the bug, and assumes the use of the largest supported node/leaf size, 64K.

$ mkfs.btrfs -f -n 65536 /dev/sdc
$ mount /dev/sdc /mnt

$ mkdir /mnt/testdir
$ chmod 755 /mnt/testdir

$ for ((i = 1; i <= 120; i++)); do
      echo -n > /mnt/testdir/file$i
   done
   
$ mkdir /mnt/testdir/dira
$ sync
$ chmod 700 /mnt/testdir

In this example, the testdir directory is inode 257, and the dira directory is inode 1458. After creating and modifying several files and directories within the testing layout, the bug is triggered when syncing inode 257 (testdir).

To fix this vulnerability, a patch has been released for the Linux kernel which ensures the proper directory entries are logged and maintained. It addresses the issue by correctly handling the case where the old parent of a moved file/directory is not authoritative for a range that includes the dir index and dir item keys of the old dentry. This patch has been tested and found to be effective in preventing the issue from occurring in the affected scenario.

For more information on the specific changes made in this patch, please refer to the original references:

- Linux kernel source code
- CVE-2021-47072 details

Though the exploit's impact may be limited due to the specific layout required to trigger the bug, users are strongly advised to update their Linux kernel to a patched version as soon as possible to avoid any potential security risks associated with this vulnerability.

Timeline

Published on: 03/01/2024 22:15:47 UTC
Last modified on: 05/29/2024 05:01:38 UTC