In the Linux kernel, the following vulnerability has been resolved: ext4: avoid infinite loops caused by residual data On the mkdir/mknod path, when mapping logical blocks to physical blocks, if inserting a new extent into the extent tree fails (in this example, because the file system disabled the huge file feature when marking the inode as dirty), ext4_ext_map_blocks() only calls ext4_free_blocks() to reclaim the physical block without deleting the corresponding data in the extent tree. This causes subsequent mkdir operations to reference the previously reclaimed physical block number again, even though this physical block is already being used by the xattr block. Therefore, a situation arises where both the directory and xattr are using the same buffer head block in memory simultaneously. The above causes ext4_xattr_block_set() to enter an infinite loop about "inserted" and cannot release the inode lock, ultimately leading to the 143s blocking problem mentioned in [1]. If the metadata is corrupted, then trying to remove some extent space can do even more harm. Also in case EXT4_GET_BLOCKS_DELALLOC_RESERVE was passed, remove space wrongly update quota information. Jan Kara suggests distinguishing between two cases: 1) The error is ENOSPC or EDQUOT - in this case the filesystem is fully consistent and we must maintain its consistency including all the accounting. However these errors can happen only early before we've inserted the extent into the extent tree. So current code works correctly for this case. 2) Some other error - this means metadata is corrupted. We should strive to do as few modifications as possible to limit damage. So I'd just skip freeing of allocated blocks. [1] INFO: task syz.0.17:5995 blocked for more than 143 seconds. Call Trace: inode_lock_nested include/linux/fs.h:1073 [inline] __start_dirop fs/namei.c:2923 [inline] start_dirop fs/namei.c:2934 [inline]
On the mkdir/mknod operation path, when inserting a new extent into the extent tree fails, the ext4_ext_map_blocks() function frees the physical block via ext4_free_blocks(), but does not remove the corresponding entry from the extent tree. Subsequent mkdir operations reference the same, already freed and reallocated physical block — causing the same block in memory to be simultaneously used by both the directory and xattr block. This results in the ext4_xattr_block_set() function entering an infinite loop, which prevents the inode lock from being released. Additionally, in case of corrupted metadata, erroneous attempts to free blocks may incorrectly update disk quota information.
An attacker or local user can trigger a persistent kernel process deadlock (denial of service) lasting over 143 seconds, and in case of corrupted metadata, can lead to further filesystem corruption and improper handling of disk quotas.
Patches available from the vendor should be applied according to references — appropriate commits are available at the addresses indicated in the references section (git.kernel.org/stable).
Linux kernel with ext4 filesystem — specific versions indicated in vendor references (commits available in kernel.org/stable repository).
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:HLinux Kernel
OSLinux2.6.227.06.7 – 6.12.80 (excl.)2.6.22.1 – 6.1.168 (excl.)6.19 – 6.19.11 (excl.)6.13 – 6.18.21 (excl.)6.2 – 6.6.131 (excl.)
Related vulnerabilities
Type confusion w V8 (Google Chrome) — zdalne uszkodzenie sterty
Commvault Command Center – nieuwierzytelniony RCE przez path traversal w ZIP
RCE przez YAML deserialization w IBM Aspera Faspex
RCE w VMware Workspace ONE Access i Identity Manager poprzez server-side template injection
Command Injection w VMware Workspace One Access i Identity Manager