CVE-2026-31448

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: avoid infinite loops caused by residual data<br /> <br /> On the mkdir/mknod path, when mapping logical blocks to physical blocks,<br /> if inserting a new extent into the extent tree fails (in this example,<br /> because the file system disabled the huge file feature when marking the<br /> inode as dirty), ext4_ext_map_blocks() only calls ext4_free_blocks() to<br /> reclaim the physical block without deleting the corresponding data in<br /> the extent tree. This causes subsequent mkdir operations to reference<br /> the previously reclaimed physical block number again, even though this<br /> physical block is already being used by the xattr block. Therefore, a<br /> situation arises where both the directory and xattr are using the same<br /> buffer head block in memory simultaneously.<br /> <br /> The above causes ext4_xattr_block_set() to enter an infinite loop about<br /> "inserted" and cannot release the inode lock, ultimately leading to the<br /> 143s blocking problem mentioned in [1].<br /> <br /> If the metadata is corrupted, then trying to remove some extent space<br /> can do even more harm. Also in case EXT4_GET_BLOCKS_DELALLOC_RESERVE<br /> was passed, remove space wrongly update quota information.<br /> Jan Kara suggests distinguishing between two cases:<br /> <br /> 1) The error is ENOSPC or EDQUOT - in this case the filesystem is fully<br /> consistent and we must maintain its consistency including all the<br /> accounting. However these errors can happen only early before we&amp;#39;ve<br /> inserted the extent into the extent tree. So current code works correctly<br /> for this case.<br /> <br /> 2) Some other error - this means metadata is corrupted. We should strive to<br /> do as few modifications as possible to limit damage. So I&amp;#39;d just skip<br /> freeing of allocated blocks.<br /> <br /> [1]<br /> INFO: task syz.0.17:5995 blocked for more than 143 seconds.<br /> Call Trace:<br /> inode_lock_nested include/linux/fs.h:1073 [inline]<br /> __start_dirop fs/namei.c:2923 [inline]<br /> start_dirop fs/namei.c:2934 [inline]