CVE-2026-31448
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 sugges
취약점 유형
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 sugges
영향받는 제품
- linux linux_kernel
참고 자료
- https://git.kernel.org/stable/c/3a7667595bcad84da53fc156a418e110267c3412
- https://git.kernel.org/stable/c/416c86f30f91b4fb2642ef6b102596ca898f41a5
- https://git.kernel.org/stable/c/5422fe71d26d42af6c454ca9527faaad4e677d6c
- https://git.kernel.org/stable/c/64f425b06b3bea9abc8977fd3982779b3ad070c9
- https://git.kernel.org/stable/c/c66545e83a802c3851d9be27a41c0479dd29ff0c
- https://git.kernel.org/stable/c/ecc50bfca9b5c2ee6aeef998181689b80477367b
공격자보다 먼저 취약점을 찾으세요.
GitHub로 로그인하고 1분 안에 첫 감사를 실행하세요. 무료 플랜은 신용카드가 필요 없습니다.