CVE-2022-49880 in Linux
Summary
by MITRE • 05/01/2025
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix warning in 'ext4_da_release_space'
Syzkaller report issue as follows: EXT4-fs (loop0): Free/Dirty block details EXT4-fs (loop0): free_blocks=0 EXT4-fs (loop0): dirty_blocks=0 EXT4-fs (loop0): Block reservation details EXT4-fs (loop0): i_reserved_data_blocks=0 EXT4-fs warning (device loop0): ext4_da_release_space:1527: ext4_da_release_space: ino 18, to_free 1 with only 0 reserved data blocks ------------[ cut here ]------------
WARNING: CPU: 0 PID: 92 at fs/ext4/inode.c:1528 ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1524 Modules linked in: CPU: 0 PID: 92 Comm: kworker/u4:4 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Workqueue: writeback wb_workfn (flush-7:0) RIP: 0010:ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1528 RSP: 0018:ffffc900015f6c90 EFLAGS: 00010296 RAX: 42215896cd52ea00 RBX: 0000000000000000 RCX: 42215896cd52ea00 RDX: 0000000000000000 RSI: 0000000080000001 RDI: 0000000000000000 RBP: 1ffff1100e907d96 R08: ffffffff816aa79d R09: fffff520002bece5 R10: fffff520002bece5 R11: 1ffff920002bece4 R12: ffff888021fd2000 R13: ffff88807483ecb0 R14: 0000000000000001 R15: ffff88807483e740 FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555569ba628 CR3: 000000000c88e000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ext4_es_remove_extent+0x1ab/0x260 fs/ext4/extents_status.c:1461 mpage_release_unused_pages+0x24d/0xef0 fs/ext4/inode.c:1589 ext4_writepages+0x12eb/0x3be0 fs/ext4/inode.c:2852 do_writepages+0x3c3/0x680 mm/page-writeback.c:2469 __writeback_single_inode+0xd1/0x670 fs/fs-writeback.c:1587 writeback_sb_inodes+0xb3b/0x18f0 fs/fs-writeback.c:1870 wb_writeback+0x41f/0x7b0 fs/fs-writeback.c:2044 wb_do_writeback fs/fs-writeback.c:2187 [inline]
wb_workfn+0x3cb/0xef0 fs/fs-writeback.c:2227 process_one_work+0x877/0xdb0 kernel/workqueue.c:2289 worker_thread+0xb14/0x1330 kernel/workqueue.c:2436 kthread+0x266/0x300 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
Above issue may happens as follows: ext4_da_write_begin ext4_create_inline_data ext4_clear_inode_flag(inode, EXT4_INODE_EXTENTS); ext4_set_inode_flag(inode, EXT4_INODE_INLINE_DATA); __ext4_ioctl ext4_ext_migrate -> will lead to eh->eh_entries not zero, and set extent flag ext4_da_write_begin ext4_da_convert_inline_data_to_extent ext4_da_write_inline_data_begin ext4_da_map_blocks ext4_insert_delayed_block if (!ext4_es_scan_clu(inode, &ext4_es_is_delonly, lblk)) if (!ext4_es_scan_clu(inode, &ext4_es_is_mapped, lblk)) ext4_clu_mapped(inode, EXT4_B2C(sbi, lblk)); -> will return 1 allocated = true; ext4_es_insert_delayed_block(inode, lblk, allocated); ext4_writepages mpage_map_and_submit_extent(handle, &mpd, &give_up_on_write); -> return -ENOSPC mpage_release_unused_pages(&mpd, give_up_on_write); -> give_up_on_write == 1 ext4_es_remove_extent ext4_da_release_space(inode, reserved); if (unlikely(to_free > ei->i_reserved_data_blocks)) -> to_free == 1 but ei->i_reserved_data_blocks == 0 -> then trigger warning as above
To solve above issue, forbid inode do migrate which has inline data.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 03/15/2026
The vulnerability described in CVE-2022-49880 affects the Linux kernel's ext4 file system implementation, specifically within the delayed allocation mechanism. This issue manifests as a warning message during writeback operations when the kernel attempts to release space for delayed blocks, but encounters a discrepancy between reserved and actually freed blocks. The warning originates from the ext4_da_release_space function located in fs/ext4/inode.c at line 1528, indicating that the system is attempting to free more blocks than were previously reserved for an inode. The condition check that triggers this warning involves comparing the number of blocks to be freed with the reserved data blocks, where the latter is zero, causing an unexpected state transition that should not occur under normal circumstances. This situation arises during complex file system operations involving inline data and extent migration, which creates a race condition or inconsistent state management within the ext4 delayed allocation subsystem.
The root cause of this vulnerability stems from a logical inconsistency in how the ext4 file system handles inodes that contain inline data during migration operations. When an inode transitions from inline data storage to extent-based storage through the ext4_ext_migrate function, the system modifies the inode's metadata flags and extent entries. However, the delayed allocation mechanism does not properly account for this transition, particularly when the inode already contains inline data that has been partially converted to extents. The sequence of operations involving ext4_da_write_begin, ext4_da_convert_inline_data_to_extent, and subsequent mapping functions creates a scenario where delayed blocks are inserted into the extent status tree without proper reservation accounting. This leads to a state where the system believes it should be able to free blocks that were never actually reserved, creating a discrepancy that triggers the warning mechanism. The vulnerability is classified under CWE-129 as an improper validation of array indices, though it manifests more specifically as a resource management inconsistency within the kernel's file system layer. The ATT&CK framework categorizes this under privilege escalation through kernel vulnerabilities, as this could potentially be leveraged to disrupt system operations or create conditions for further exploitation.
The operational impact of this vulnerability primarily involves system stability and reliability rather than direct security compromise. The warning message itself does not cause system crashes or data corruption, but it indicates an underlying inconsistency that could potentially lead to more severe issues under specific conditions. When the system encounters this warning during writeback operations, it suggests that the file system's internal accounting mechanisms have become inconsistent, which may result in delayed allocation behavior becoming unpredictable. This could manifest as performance degradation during file write operations, particularly when dealing with files that undergo transitions between inline data and extent-based storage. The warning is particularly concerning in high-throughput environments where frequent writeback operations occur, as it may indicate broader issues with block reservation and release mechanisms that could eventually lead to resource exhaustion or allocation failures. The vulnerability affects systems running Linux kernel versions where the ext4 file system is used for storage, with particular impact on systems handling large numbers of files that undergo inline data conversion.
Mitigation strategies for this vulnerability focus on preventing the problematic code path rather than patching the immediate warning. The primary solution involves modifying the ext4 file system implementation to prevent inodes containing inline data from undergoing extent migration operations. This is achieved by adding a check that forbids migration of inodes that have already been converted to inline data storage, effectively preventing the inconsistent state that leads to the warning. The patch implements a conditional check before executing the ext4_ext_migrate function, ensuring that inodes with the EXT4_INODE_INLINE_DATA flag are not processed for extent migration. This approach aligns with defensive programming practices that prevent state transitions that could lead to inconsistent internal data structures. System administrators should ensure that their Linux kernels are updated to versions that include this patch, particularly in production environments where file system stability is critical. The fix also emphasizes proper resource management and accounting within the delayed allocation subsystem, ensuring that block reservation and release operations maintain consistency throughout the file system's lifecycle. Organizations should monitor their systems for similar warnings and consider implementing additional logging to track when such conditions occur, as they may indicate other underlying file system issues that require further investigation.