CVE-2026-31448

What it is

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]

At a glance

Exploitability

Can be exploited over the network without logging in. High risk of data tampering, service disruption.

Exploit odds

0.5% chance of exploitation in the next 30 days (EPSS).

Fix

A patch, advisory or fixed version is referenced. Upgrade or apply it.

Timeline

1. 2026-04-22 14:16 UTC PublishedDisclosed publicly on CVE.org and NVD
2. 2026-10-19 19:17 UTC Last updatedMost recent change to the record

Why it ranks here

• Exploited in the wild: no, CISA does not list it.
• Exploit odds: 0.5% in the next 30 days (EPSS).
• Severity: 9.4 CRITICAL (CVSS).
• Fix: a patch or advisory is linked.

Details

Published

2026-04-22 14:16 UTC

Last modified

2026-10-19 19:17 UTC

Exploit probability

0.5% · EPSS, next 30 days

Weakness

CWE-835

Record status

Modified

Affected

• Linux Kernel < 6.1.168
• Linux Kernel < 6.6.131
• Linux Kernel < 6.12.80
• Linux Kernel < 6.18.21
• Linux Kernel < 6.19.11
• Linux Kernel 2.6.22
• Linux Kernel 7.0

Attack profile CVSS 3.1 · 9.4

Attack vector

Network

Complexity

Low

Privileges needed

None

User interaction

None

Scope

Unchanged

Confidentiality

Low

Integrity

High

Availability

High

Is it in your code?

Hand this to your coding agent. It searches your project for the affected products and checks versions. Nothing leaves your machine.

Read https://cve-list.com/agent/cve/CVE-2026-31448.md and follow it. Check whether this project is affected by CVE-2026-31448. Read only. Don't change anything and don't upload my code. Tell me yes, no or not sure, with the file as proof.

Copy as ticket · More options · Status badge