Linux: Loop with Unreachable Exit Condition

What to do

1. Update Linux to c66545e83a802c3851d9be27a41c0479dd29ff0c or ecc50bfca9b5c2ee6aeef998181689b80477367b or 3a7667595bcad84da53fc156a418e110267c3412 or 416c86f30f91b4fb2642ef6b102596ca898f41a5, whichever matches your release line, or a later version.
2. Update Linux Kernel to 6.1.168 or 6.6.131 or 6.12.80 or 6.18.21, whichever matches your release line, or a later version.
3. Until you can update, restrict network access to the affected service so it is not reachable from untrusted networks.

Affected products and versions

Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.

How the severity score breaks down

Attack vector

NetworkCan be exploited remotely over a network, including the internet.

Attack complexity

LowNo special conditions are needed; the attack works reliably.

Privileges required

NoneNo account or login is needed.

User interaction

NoneNo action by a victim is required.

Scope

UnchangedImpact stays within the vulnerable component.

Confidentiality

LowSome restricted data can be read.

Integrity

HighData or code can be modified at will.

Availability

HighThe component can be taken down completely.

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H. Scored by CNA.

Official 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]

Source: the CVE record as published by its numbering authority, via NVD and CVE.org.

The underlying weakness: Loop with Unreachable Exit Condition

Timeline

1. April 22, 2026CVE record published.
2. October 16, 2026CISA published its SSVC assessment (exploitation: none, automatable: yes, technical impact: partial).
3. November 11, 2026Record last changed materially (score, affected products, status or references).

References

Recent Loop with Unreachable Exit Condition vulnerabilities

• 7.5 High severity

  aardvark-dns: Loop with Unreachable Exit Condition

  CVE-2026-35406Apr 7, 2026Containers
• 7.5 High severity

  Linux: Loop with Unreachable Exit Condition

  CVE-2026-23451Apr 3, 2026Linux
• 7.5 High severity

  forge: Loop with Unreachable Exit Condition

  CVE-2026-33891Mar 27, 2026Digitalbazaar
• 7.5 High severity

  pypdf: Loop with Unreachable Exit Condition

  CVE-2026-33699Mar 27, 2026Py-pdf
• 7.5 High severity

  github.com/antchfx/xpath: Loop with Unreachable Exit Condition

  CVE-2026-32287Mar 26, 2026Github.com/antchfx/xpath
• 7.5 High severity

  jsrsasign: Loop with Unreachable Exit Condition

  CVE-2026-4598Mar 23, 2026Jsrsasign

Spotted an error? Tell us.