A vulnerability was found in the Linux kernel’s btrfs module, where there are a few exceptional cases when cloning an inline extent needs to copy the inline extent data into a page of the destination inode. When this happens, a transaction starts while having a dirty page for the destination inode and while having the range locked in the destination’s inode iotree. When reserving metadata space for a transaction, flushing the existing delalloc is needed in case there is not enough free space. There is a mechanism in place to prevent a deadlock, which was introduced in commit 3d45f221ce627d (“btrfs: fix deadlock when cloning inline extent and low on free metadata space”). However, when using qgroups, a transaction also reserves metadata qgroup space, which can also result in flushing delalloc in case there is not enough available space. When this happens, a deadlock occurs, since flushing delalloc requires locking the file range in the inode’s iotree and the range was already locked at the very beginning of the clone operation, before attempting to start the transaction.
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.