9.4 CVE-2026-31448
Enriched by CISA Patch
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]
https://nvd.nist.gov/vuln/detail/CVE-2026-31448
Categories
CWE-835 : Loop with Unreachable Exit Condition ('Infinite Loop')
The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop. Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.) Chain: library for implementing Profinet devices does not check an input for a loop condition (CWE-606), allowing an infinite loop (CWE-835) via a crafted RPC packet Chain: an operating system does not properly process malformed Open Shortest Path First (OSPF) Type/Length/Value Identifiers (TLV) (CWE-703), which can cause the process to enter an infinite loop (CWE-835) A Python machine communication platform did not account for receiving a malformed packet with a null size, causing the receiving function to never update the message buffer and be caught in an infinite loop. Chain: off-by-one error (CWE-193) leads to infinite loop (CWE-835) using invalid hex-encoded characters. Chain: self-referential values in recursive definitions lead to infinite loop. NULL UDP packet is never cleared from a queue, leading to infinite loop. Chain: web browser crashes due to infinite loop - "badlooping logic [that relies on] floating point math [CWE-1339] to exitthe loop [CWE-835]" Floating point conversion routine cycles back and forth between two different values. Floating point conversion routine cycles back and forth between two different values. Chain: improperly clearing a pointer in a linked list leads to infinite loop. Chain: an integer overflow (CWE-190) in the image size calculation causes an infinite loop (CWE-835) which sequentially allocates buffers without limits (CWE-1325) until the stack is full. Chain: A denial of service may be caused by an uninitialized variable (CWE-457) allowing an infinite loop (CWE-835) resulting from a connection to an unresponsive server.
References
0b142b55-0307-4c5a-b3c9-f314f3fb7c5e
| https://cert-portal.siemens.com/productcert/html/ssa-019113.html |
| https://cert-portal.siemens.com/productcert/html/ssa-082556.html |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 Patch
AFFECTED (from MITRE)
| Vendor | Product | Versions |
|---|---|---|
| Linux | Linux |
|
| Linux | Linux |
|
| © 2022 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. | ||
CPE
| cpe | start | end |
|---|---|---|
| Configuration 1 | ||
| cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | >= 2.6.22.1 | < 6.1.168 |
| cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | >= 6.2 | < 6.6.131 |
| cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | >= 6.7 | < 6.12.80 |
| cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | >= 6.13 | < 6.18.21 |
| cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | >= 6.19 | < 6.19.11 |
| 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:*:*:*:*:*:* | ||
REMEDIATION
Patch
EXPLOITS
Exploit-db.com
| id | description | date | |
|---|---|---|---|
| No known exploits | |||
POC Github
| Url |
|---|
| No known exploits |
Other Nist (github, ...)
| Url |
|---|
| No known exploits |
CAPEC
Common Attack Pattern Enumerations and Classifications
| id | description | severity |
|---|---|---|
| No entry | ||
Cybersecurity needs ?
Strengthen software security from the outset with our DevSecOps expertise
Integrate security right from the start of the software development cycle for more robust applications and greater customer confidence.
Our team of DevSecOps experts can help you secure your APIs, data pipelines, CI/CD chains, Docker containers and Kubernetes deployments.
