Status: UPDATED | Advisory ID: CVE-2026-31448
| CVE | CVE-2026-31448 |
| CVSS Score / Version | 9.4 (Critical) / CVSS v3.1 |
| Updated | 2026-07-14 |
| CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H |
| CVSS Prose | attack vector is network; attack complexity is low; privileges required is none; user interaction is none; scope is unchanged; confidentiality impact is low; integrity impact is high; availability impact is high. |
| Affected products | Siemens SIMATIC S7-1500 CPU 1518-4 PN/DP MFP, Siemens SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP, and Siemens SIPLUS S7-1500 CPU 1518-4 PN/DP MFP |
| Classified as | CWE-835 (Loop with Unreachable Exit Condition ('Infinite Loop')) |
| Vendor | Product | Affected Versions | Patch Status |
|---|---|---|---|
| Siemens | SIMATIC S7-1500 CPU 1518-4 PN/DP MFP | ||
| Siemens | SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP | ||
| Siemens | SIPLUS S7-1500 CPU 1518-4 PN/DP MFP |
| Subsystems | General OT |
| Sectors | Multiple |
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] (NVD)
Monitor Siemens's web page for any future patch releases.
| Source | Reference |
|---|---|
| NVD | https://nvd.nist.gov/vuln/detail/CVE-2026-31448 |
| CVE | https://www.cve.org/CVERecord?id=CVE-2026-31448 |