Skip to main content
VulnerabilityPublished Updated

CVE-2026-31448: Linux kernel · ext4: avoid infinite loops caused by residual data

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · CVSS 9.4 Critical · fixed in ecc50bfca9b5c2ee6aeef998181689b80477367b : patch Linux kernel as a priority.

Data as of 26 Oct 2026, 11:20 UTC

CVSS 3.1 base score
9.4Critical
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.4% chance of exploitation in 30 days – higher than 42% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers can reliably automate steps 1–4 of the kill chain
Technical impact
Limited control over the software or limited information exposure

CISA SSVC assessment, 2026-10-16.

Patch
Available – fixed in ecc50bfca9b5c2ee6aeef998181689b80477367b, c66545e83a802c3851d9be27a41c0479dd29ff0c, 5422fe71d26d42af6c454ca9527faaad4e677d6c +3
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 22 Apr 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ 315054f023d28ee64f308adf8b5737831541776b, < ecc50bfca9b5c2ee6aeef998181689b80477367b
Fixed in
  • ecc50bfca9b5c2ee6aeef998181689b80477367b
LinuxLinuxAffected
  • ≥ 315054f023d28ee64f308adf8b5737831541776b, < c66545e83a802c3851d9be27a41c0479dd29ff0c
Fixed in
  • c66545e83a802c3851d9be27a41c0479dd29ff0c
LinuxLinuxAffected
  • ≥ 315054f023d28ee64f308adf8b5737831541776b, < 5422fe71d26d42af6c454ca9527faaad4e677d6c
Fixed in
  • 5422fe71d26d42af6c454ca9527faaad4e677d6c
LinuxLinuxAffected
  • ≥ 315054f023d28ee64f308adf8b5737831541776b, < 416c86f30f91b4fb2642ef6b102596ca898f41a5
Fixed in
  • 416c86f30f91b4fb2642ef6b102596ca898f41a5
LinuxLinuxAffected
  • ≥ 315054f023d28ee64f308adf8b5737831541776b, < 64f425b06b3bea9abc8977fd3982779b3ad070c9
Fixed in
  • 64f425b06b3bea9abc8977fd3982779b3ad070c9
LinuxLinuxAffected
  • ≥ 315054f023d28ee64f308adf8b5737831541776b, < 3a7667595bcad84da53fc156a418e110267c3412
Fixed in
  • 3a7667595bcad84da53fc156a418e110267c3412

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]

References

Community reviews

Loading reviews…