CVE-2021-47072: Vulnerability in Linux Linux

Severity: highType: vulnerabilityCVE-2021-47072

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix removed dentries still existing after log is synced When 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 the # fs/subvolume btree to trigger the bug. So we want to make sure that # on whatever platform we are, we have the same leaf/node size. # # Currently in btrfs the node/leaf size can not be smaller than the page # size (but it can be greater than the page size). So use the largest # supported 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/testdir # Create several empty files to have the directory "testdir" with its # items spread over several leaves (7 in this case). $ for ((i = 1; i <= 1200; i++)); do echo -n > /mnt/testdir/file$i done # Create our test directory "dira", inode number 1458, which gets all # its items in leaf 7. # # The BTRFS_DIR_ITEM_KEY item for inode 257 ("testdir") that points to # the entry named "dira" is in leaf 2, while the BTRFS_DIR_INDEX_KEY # item that points to that entry is in leaf 3. # # For this particular filesystem node size (64K), file count and file # names, we endup with the directory entry items from inode 257 in # leaves 2 and 3, as previously mentioned - what matters for triggering # the bug exercised by this test case is that those items are not placed # in leaf 1, they must be placed in a leaf different from the one # containing the inode item for inode 257. # # The corresponding BTRFS_DIR_ITEM_KEY and BTRFS_DIR_INDEX_KEY items for # the parent inode (257) are the following: # # item 460 key (257 DIR_ITEM 3724298081) itemoff 48344 itemsize 34 # location key (1458 INODE_ITEM 0) type DIR # transid 6 data_len 0 name_len 4 # name: dira # # and: # # item 771 key (257 DIR_INDEX 1202) itemoff 36673 itemsize 34 # location key (1458 INODE_ITEM 0) type DIR # transid 6 data_len 0 name_len 4 # name: dira $ mkdir /mnt/testdir/dira # Make sure everything done so far is durably persisted. $ sync # Now do a change to inode 257 ("testdir") that does not result in # COWing leaves 2 and 3 - the leaves that contain the directory items # pointing 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 of # simplicity change the permissions of inode 257, which results in # updating its inode item and therefore change (COW) only leaf 1. $ chmod 700 /mnt/testdir # Now fsync directory inode 257. # # Since only the first leaf was changed/COWed, we log the inode item of # inode 257 and only the dentries found in the first leaf, all have a # key type of BTRFS_DIR_ITEM_KEY, and no keys of type # BTRFS_DIR_INDEX_KEY, because they sort after the former type and none # exist in the first leaf. # # We also log 3 items that represent ranges for dir items and dir # indexes for which the log is authoritative: # # 1) a key of type BTRFS_DIR_LOG_ITEM_KEY, which indicates the log is # authoritative for all BTRFS_DIR_ITEM_KEY keys that have an offset # in the range [0, 2285968570] (the offset here is th ---truncated---

AI Analysis

Technical Summary

CVE-2021-47072 is a vulnerability identified in the Linux kernel's Btrfs filesystem implementation. The issue arises from improper handling of directory entries (dentries) during inode moves between directories, specifically when both the inode and its previous parent directory have been logged before a power failure occurs after the log synchronization. Under normal operation, after moving an inode from one directory to another, the old dentry should no longer exist if the log has been synced and a power failure happens. However, due to a flaw in the authoritative range determination for directory items and directory index keys, the old parent directory may still retain stale dentries. This inconsistency can lead to filesystem corruption or data integrity issues. The vulnerability is triggered under very specific filesystem layouts involving large node/leaf sizes (64K), multiple directory items spread across several leaves, and particular inode and directory index key placements. The problem stems from the logging mechanism not correctly accounting for all directory index keys in the authoritative range, causing the old dentry to persist erroneously after recovery from a power failure. This can result in stale or inconsistent directory entries, potentially leading to data loss, filesystem corruption, or unexpected behavior in applications relying on the filesystem's integrity. Although the vulnerability requires a very specific filesystem state and sequence of operations to be triggered, it affects the core Linux kernel Btrfs implementation, which is widely used in various Linux distributions. No known exploits are currently reported in the wild, and no CVSS score has been assigned yet.

Potential Impact

For European organizations, especially those relying on Linux servers with Btrfs filesystems for critical data storage, this vulnerability poses a risk of filesystem corruption and data integrity loss. This can disrupt business operations, cause downtime, and lead to potential data loss or the need for costly recovery efforts. Organizations running database servers, file servers, or virtualized environments on Btrfs are particularly at risk. The impact is more pronounced in environments with frequent inode moves or heavy filesystem modifications, increasing the likelihood of triggering the bug. Additionally, sectors such as finance, healthcare, and government agencies in Europe, which often require high data integrity and availability, could face operational and compliance challenges if affected. While exploitation requires specific conditions and no remote code execution vector is evident, the risk of data corruption and availability issues warrants prompt attention. The lack of known exploits reduces immediate threat levels but does not eliminate the risk of accidental triggering or future exploitation by sophisticated attackers.

Mitigation Recommendations

European organizations should prioritize updating their Linux kernel to versions where this vulnerability is patched. Since the issue relates to the Btrfs filesystem's internal logging and inode move operations, applying the official kernel patches or upgrading to a kernel version released after the fix is essential. Administrators should audit systems using Btrfs, especially those with large directories and frequent inode moves, to identify potential exposure. Implementing robust backup and recovery procedures is critical to mitigate data loss risks. Additionally, organizations can reduce the risk by limiting operations that move inodes between directories on production systems until patched. Monitoring system logs for filesystem errors or inconsistencies can help detect early signs of corruption. For environments where immediate patching is not feasible, consider migrating critical data to alternative filesystems less affected by this issue, such as ext4 or XFS, until a patch is applied. Finally, testing the patch in staging environments is recommended to ensure compatibility and stability before deployment.