CyberIntel ⬡ News
★ Saved ◆ Cyber Reads
← Back ⬡ Vulnerabilities & CVEs Apr 22, 2026

CVE-2026-31448 | Linux Kernel up to 6.19.10 ext4_ext_map_blocks infinite loop

VulDB Archived Apr 22, 2026 ✓ Full text saved

A vulnerability was found in Linux Kernel up to 6.1.167/6.6.130/6.12.79/6.18.20/6.19.10 . It has been rated as critical . This impacts the function ext4_ext_map_blocks . This manipulation causes infinite loop. The identification of this vulnerability is CVE-2026-31448 . The attack needs to be done within the local network. There is no exploit available. Upgrading the affected component is advised.

Full text archived locally
✦ AI Summary · Claude Sonnet


    VDB-358940 · CVE-2026-31448 · GCVE-0-2026-31448 LINUX KERNEL UP TO 6.19.10 EXT4_EXT_MAP_BLOCKS INFINITE LOOP HISTORYDIFFRELATEJSONXMLCTI CVSS Meta Temp Score Current Exploit Price (≈) CTI Interest Score 4.6 $0-$5k 0.00+ Summaryinfo A vulnerability categorized as critical has been discovered in Linux Kernel up to 6.1.167/6.6.130/6.12.79/6.18.20/6.19.10. Affected is the function ext4_ext_map_blocks. Such manipulation leads to infinite loop. This vulnerability is referenced as CVE-2026-31448. No exploit is available. It is advisable to upgrade the affected component. Detailsinfo A vulnerability, which was classified as critical, has been found in Linux Kernel up to 6.1.167/6.6.130/6.12.79/6.18.20/6.19.10. Affected by this issue is the function ext4_ext_map_blocks. The manipulation with an unknown input leads to a infinite loop vulnerability. Using CWE to declare the problem leads to CWE-835. The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop. Impacted is availability. CVE summarizes: 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] The advisory is shared for download at git.kernel.org. This vulnerability is handled as CVE-2026-31448 since 03/09/2026. The exploitation is known to be difficult. There are known technical details, but no exploit is available. Upgrading to version 6.1.168, 6.6.131, 6.12.80, 6.18.21 or 6.19.11 eliminates this vulnerability. Applying the patch c66545e83a802c3851d9be27a41c0479dd29ff0c/ecc50bfca9b5c2ee6aeef998181689b80477367b/3a7667595bcad84da53fc156a418e110267c3412/416c86f30f91b4fb2642ef6b102596ca898f41a5/64f425b06b3bea9abc8977fd3982779b3ad070c9/5422fe71d26d42af6c454ca9527faaad4e677d6c is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version. Productinfo Type Operating System Vendor Linux Name Kernel Version 6.1.167 6.6.130 6.12.0 6.12.1 6.12.2 6.12.3 6.12.4 6.12.5 6.12.6 6.12.7 6.12.8 6.12.9 6.12.10 6.12.11 6.12.12 6.12.13 6.12.14 6.12.15 6.12.16 6.12.17 6.12.18 6.12.19 6.12.20 6.12.21 6.12.22 6.12.23 6.12.24 6.12.25 6.12.26 6.12.27 6.12.28 6.12.29 6.12.30 6.12.31 6.12.32 6.12.33 6.12.34 6.12.35 6.12.36 6.12.37 6.12.38 6.12.39 6.12.40 6.12.41 6.12.42 6.12.43 6.12.44 6.12.45 6.12.46 6.12.47 6.12.48 6.12.49 6.12.50 6.12.51 6.12.52 6.12.53 6.12.54 6.12.55 6.12.56 6.12.57 6.12.58 6.12.59 6.12.60 6.12.61 6.12.62 6.12.63 6.12.64 6.12.65 6.12.66 6.12.67 6.12.68 6.12.69 6.12.70 6.12.71 6.12.72 6.12.73 6.12.74 6.12.75 6.12.76 6.12.77 6.12.78 6.12.79 6.18.0 6.18.1 6.18.2 6.18.3 6.18.4 6.18.5 6.18.6 6.18.7 6.18.8 6.18.9 6.18.10 6.18.11 6.18.12 6.18.13 6.18.14 6.18.15 6.18.16 6.18.17 6.18.18 6.18.19 6.18.20 6.19.0 6.19.1 6.19.2 6.19.3 6.19.4 6.19.5 6.19.6 6.19.7 6.19.8 6.19.9 6.19.10 License open-source Website Vendor: https://www.kernel.org/ CPE 2.3info 🔒 🔒 🔒 CPE 2.2info 🔒 🔒 🔒 CVSSv4info VulDB Vector: 🔒 VulDB Reliability: 🔍 CVSSv3info VulDB Meta Base Score: 4.8 VulDB Meta Temp Score: 4.6 VulDB Base Score: 4.8 VulDB Temp Score: 4.6 VulDB Vector: 🔒 VulDB Reliability: 🔍 CVSSv2info Vector Complexity Authentication Confidentiality Integrity Availability Unlock Unlock Unlock Unlock Unlock Unlock Unlock Unlock Unlock Unlock Unlock Unlock Unlock Unlock Unlock Unlock Unlock Unlock VulDB Base Score: 🔒 VulDB Temp Score: 🔒 VulDB Reliability: 🔍 Exploitinginfo Class: Infinite loop CWE: CWE-835 / CWE-404 CAPEC: 🔒 ATT&CK: 🔒 Physical: No Local: No Remote: Partially Availability: 🔒 Status: Not defined Price Prediction: 🔍 Current Price Estimation: 🔒 0-Day Unlock Unlock Unlock Unlock Today Unlock Unlock Unlock Unlock Threat Intelligenceinfo Interest: 🔍 Active Actors: 🔍 Active APT Groups: 🔍 Countermeasuresinfo Recommended: Upgrade Status: 🔍 0-Day Time: 🔒 Upgrade: Kernel 6.1.168/6.6.131/6.12.80/6.18.21/6.19.11 Patch: c66545e83a802c3851d9be27a41c0479dd29ff0c/ecc50bfca9b5c2ee6aeef998181689b80477367b/3a7667595bcad84da53fc156a418e110267c3412/416c86f30f91b4fb2642ef6b102596ca898f41a5/64f425b06b3bea9abc8977fd3982779b3ad070c9/5422fe71d26d42af6c454ca9527faaad4e677d6c Timelineinfo 03/09/2026 CVE reserved 04/22/2026 +43 days Advisory disclosed 04/22/2026 +0 days VulDB entry created 04/22/2026 +0 days VulDB entry last update Sourcesinfo Vendor: kernel.org Advisory: git.kernel.org Status: Confirmed CVE: CVE-2026-31448 (🔒) GCVE (CVE): GCVE-0-2026-31448 GCVE (VulDB): GCVE-100-358940 Entryinfo Created: 04/22/2026 17:23 Changes: 04/22/2026 17:23 (58) Complete: 🔍 Cache ID: 99:EAF:101 Discussion No comments yet. Languages: en. Please log in to comment. ◂ PreviousOverviewNext ▸
    💬 Team Notes
    Article Info
    Source
    VulDB
    Category
    ⬡ Vulnerabilities & CVEs
    Published
    Apr 22, 2026
    Archived
    Apr 22, 2026
    Full Text
    ✓ Saved locally
    Open Original ↗