Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:HCVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.
Summary
CVE-2026-31448 is a critical-severity Infinite Loop (CWE-835) vulnerability in Linux Linux Kernel. Its CVSS base score is 9.4 (Critical).
Operationally, exploitation aligns with the MITRE ATT&CK technique Data Obfuscation (T1001); ranked at the 37th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SI-2 (Flaw Remediation) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-31448 is a vulnerability in the Linux kernel's ext4 filesystem that causes infinite loops due to residual data in the extent tree. During mkdir or mknod operations, when mapping logical blocks to physical blocks, inserting a new extent may fail—for instance, if the filesystem disables the huge file feature while marking the inode as dirty. In such cases, ext4_ext_map_blocks() reclaims the physical block via ext4_free_blocks() without deleting the corresponding entry from the extent tree. Subsequent operations then reference the reclaimed block, which is reused by an xattr block, leading both the directory and xattr to share the same buffer head in memory and triggering an infinite loop in ext4_xattr_block_set(). This results in prolonged inode lock blocking, such as the observed 143-second task blockage.
The vulnerability carries a CVSS score of 9.4 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H), allowing exploitation by unauthenticated remote attackers with low attack complexity and no user interaction. Exploits occur via filesystem operations like mkdir or mknod on affected ext4 volumes, causing denial-of-service through indefinite task blocking on the inode lock. Additional risks include further metadata corruption during extent removal attempts and incorrect quota updates if EXT4_GET_BLOCKS_DELALLOC_RESERVE is involved.
Upstream patches address the issue by distinguishing error cases, as suggested by Jan Kara: ENOSPC or EDQUOT errors maintain filesystem consistency and accounting (handled correctly pre-extent insertion), while other errors—indicating metadata corruption—skip block freeing to minimize damage. Relevant stable kernel commits include 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, and https://git.kernel.org/stable/c/c66545e83a802c3851d9be27a41c0479dd29ff0c. Security practitioners should update to patched kernels.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-24784
Vulnerability Data
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…
more
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]
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation can discover unreachable loop exit conditions through static analysis, fuzzing, or execution tracing.
Flaw remediation processes identify and correct infinite-loop defects reported from testing or operations.
Requiring documented development processes and secure coding standards reduces introduction of loops whose termination conditions are unreachable.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.