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]
Published: 2026-04-22
Score: 9.4 Critical
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

In the Linux kernel’s ext4 file system, a failure to cleanly remove a failed extent insertion leads to an infinite loop within ext4_xattr_block_set. The loop continually attempts to mark the same buffer head as inserted, preventing the inode lock from being released. As a result, tasks that try to create or manipulate directories hang for extended periods, effectively disabling filesystem operations on affected paths. The vulnerability triggers a denial of service, but does not leak data, execute code, or provide privilege escalation.

Affected Systems

All Linux kernel builds that compile ext4 and have not incorporated the patches referenced in the commit logs are vulnerable. The fix is present in the commits cited in the advisory (e.g., 3a7667595bcad84da53fc156a418e110267c3412). Administrators should verify that their current kernel image contains these changes, or plan to upgrade to a kernel release that includes the updated ext4 code.

Risk and Exploitability

The flaw requires write access to the filesystem to trigger the problematic extent logic, limiting exploitation to local users with directory creation rights. The CVSS score of 9.4 indicates critical severity, while the EPSS score of less than 1% suggests a low current exploitation probability. The vulnerability is not listed in the CISA KEV catalog. Although exploitation attempts are unlikely at present, the blocking behavior can severely impact operations, warranting prompt remediation.

Generated by OpenCVE AI on May 7, 2026 at 19:54 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Update the Linux kernel to a release that includes the patched ext4 code referenced in the commit logs.
  • Apply the specific kernel patch commits identified in the advisory to your current kernel if upgrading is not immediately possible.
  • Reboot the system or reload the ext4 module after applying the update to ensure the new logic takes effect.

Generated by OpenCVE AI on May 7, 2026 at 19:54 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DLA Debian DLA DLA-4561-1 linux-6.1 security update
Debian DSA Debian DSA DSA-6238-1 linux security update
Debian DSA Debian DSA DSA-6243-1 linux security update
History

Thu, 07 May 2026 18:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-835
CPEs cpe:2.3:o:linux:linux_kernel:2.6.22:-:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:2.6.22:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:2.6.22:rc5:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:2.6.22:rc6:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:2.6.22:rc7:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc5:*:*:*:*:*:*

Mon, 27 Apr 2026 14:15:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

cvssV3_1

{'score': 9.4, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H'}


Thu, 23 Apr 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-772
References
Metrics threat_severity

None

cvssV3_1

{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

threat_severity

Moderate


Wed, 22 Apr 2026 14:15:00 +0000

Type Values Removed Values Added
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]
Title ext4: avoid infinite loops caused by residual data
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-05-11T22:08:54.289Z

Reserved: 2026-03-09T15:48:24.091Z

Link: CVE-2026-31448

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Analyzed

Published: 2026-04-22T14:16:38.760

Modified: 2026-05-07T18:43:29.587

Link: CVE-2026-31448

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-04-22T00:00:00Z

Links: CVE-2026-31448 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-05-07T20:00:12Z

Weaknesses