ext4: avoid infinite loops caused by residual data
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | |||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Linux | Linux | unaffected |
|
|||||||||||||||||||||||||||
| Linux | Linux | affected |
|
Configuration 1 [-]
|
No data.
| Vendor | Product | Versions | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Linux | Linux Kernel |
|
||||||||||||||||||||||||||||
| Linux | Linux Kernel |
|
| Source | ID | Title |
|---|---|---|
Debian DLA |
DLA-4561-1 | linux-6.1 security update |
Debian DSA |
DSA-6238-1 | linux security update |
Debian DSA |
DSA-6243-1 | linux security update |
Ubuntu USN |
USN-8490-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-8491-1 | Linux kernel (OEM) vulnerabilities |
Ubuntu USN |
USN-8492-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-8492-2 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-8497-1 | Linux kernel (Low Latency) vulnerabilities |
Ubuntu USN |
USN-8498-1 | Linux kernel (NVIDIA Tegra) vulnerabilities |
Ubuntu USN |
USN-8499-1 | Linux kernel (Xilinx) vulnerabilities |
Ubuntu USN |
USN-8508-1 | Linux kernel (NVIDIA) vulnerabilities |
Ubuntu USN |
USN-8492-3 | Linux kernel (Raspberry Pi Real-time) vulnerabilities |
Ubuntu USN |
USN-8490-2 | Linux kernel (Real-time) vulnerabilities |
Ubuntu USN |
USN-8492-4 | Linux kernel (Raspberry Pi) vulnerabilities |
Ubuntu USN |
USN-8492-5 | Linux kernel (FIPS) vulnerabilities |
Ubuntu USN |
USN-8545-1 | Linux kernel (HWE) vulnerabilities |
Ubuntu USN |
USN-8546-1 | Linux kernel (Raspberry Pi) vulnerabilities |
Ubuntu USN |
USN-8604-1 | Linux kernel (Azure) vulnerabilities |
Ubuntu USN |
USN-8605-1 | Linux kernel (Azure CVM) vulnerabilities |
Ubuntu USN |
USN-8606-1 | Linux kernel (Azure) vulnerabilities |
Ubuntu USN |
USN-8607-1 | Linux kernel (Azure CVM) vulnerabilities |
Ubuntu USN |
USN-8609-1 | Linux kernel (Azure CVM) vulnerabilities |
Ubuntu USN |
USN-8619-1 | Linux kernel (HWE) vulnerabilities |
Ubuntu USN |
USN-8631-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-8633-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-8634-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-8635-1 | Linux kernel (Azure) vulnerabilities |
Ubuntu USN |
USN-8631-2 | Linux kernel (Oracle) vulnerabilities |
Ubuntu USN |
USN-8631-3 | Linux kernel (NVIDIA Tegra IGX) vulnerabilities |
Ubuntu USN |
USN-8633-2 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-8631-4 | Linux kernel (Azure CVM) vulnerabilities |
Ubuntu USN |
USN-8645-1 | Linux kernel (Oracle) vulnerabilities |
Ubuntu USN |
USN-8661-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-8666-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-8662-2 | Linux kernel (FIPS) vulnerabilities |
Ubuntu USN |
USN-8667-1 | Linux kernel (KVM) vulnerabilities |
Ubuntu USN |
USN-8661-2 | Linux kernel (Low Latency) vulnerabilities |
Ubuntu USN |
USN-8666-2 | Linux kernel (Azure) vulnerabilities |
Ubuntu USN |
USN-8661-3 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-8666-3 | Linux kernel (GCP FIPS) vulnerabilities |
Ubuntu USN |
USN-8661-4 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-8715-1 | Linux kernel (Oracle) vulnerabilities |
Ubuntu USN |
USN-8715-2 | Linux kernel (AWS FIPS) vulnerabilities |
Ubuntu USN |
USN-8661-5 | Linux kernel (Raspberry Pi) vulnerabilities |
No CVSS v4.0
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.499% probability within 30 days)
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
| Type | Values Removed | Values Added |
|---|---|---|
| References |
|
| 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:*:*:*:*:*:* |
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
cvssV3_1
|
cvssV3_1
|
| Type | Values Removed | Values Added |
|---|---|---|
| Weaknesses | CWE-772 | |
| References |
| |
| Metrics |
threat_severity
|
cvssV3_1
|
| 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 |
|
|