CVE-2026-31448
Received Received - Intake
Infinite Loop Vulnerability in Linux ext4 Causing mkdir Hang

Publication date: 2026-04-22

Last updated on: 2026-04-27

Assigner: kernel.org

Description
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]
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-04-22
Last Modified
2026-04-27
Generated
2026-05-07
AI Q&A
2026-04-22
EPSS Evaluated
2026-05-05
NVD
CVE-2026-31448
EUVD
EUVD-2026-24784
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's ext4 file system. It occurs during the mkdir or mknod operations when mapping logical blocks to physical blocks. If inserting a new extent into the extent tree fails, the system frees the physical block but does not delete the corresponding data in the extent tree. This causes subsequent mkdir operations to reference the same physical block that is already in use by the extended attribute (xattr) block, leading to both directory and xattr using the same memory buffer simultaneously.

As a result, the ext4_xattr_block_set() function can enter an infinite loop and fail to release the inode lock, causing a blocking problem where the task is stuck for an extended period (e.g., 143 seconds). Additionally, if metadata is corrupted, attempts to remove extent space can cause further damage, including incorrect quota updates.


How can this vulnerability impact me? :

This vulnerability can cause the system to enter an infinite loop during certain file system operations, leading to tasks being blocked for long periods (such as 143 seconds). This blocking can degrade system performance and responsiveness.

Moreover, if the file system metadata is corrupted, attempts to free space may cause further damage, including incorrect quota information updates, which could affect disk usage accounting and stability.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability involves infinite loops caused by residual data in the ext4 filesystem when inserting new extents fails. Immediate mitigation should focus on avoiding operations that trigger this condition, such as mkdir or mknod operations on affected ext4 filesystems.

Since the issue arises from improper handling of extent tree updates and block freeing, applying the patch or update that resolves this issue in the Linux kernel is the recommended step.

Avoid filesystem operations that modify extents on ext4 until the fix is applied to prevent inode lock blocking and infinite loops.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart