CVE-2022-50730 in Linux
Summary
by MITRE • 12/24/2025
In the Linux kernel, the following vulnerability has been resolved:
ext4: silence the warning when evicting inode with dioread_nolock
When evicting an inode with default dioread_nolock, it could be raced by the unwritten extents converting kworker after writeback some new allocated dirty blocks. It convert unwritten extents to written, the extents could be merged to upper level and free extent blocks, so it could mark the inode dirty again even this inode has been marked I_FREEING. But the inode->i_io_list check and warning in ext4_evict_inode() missing this corner case. Fortunately, ext4_evict_inode() will wait all extents converting finished before this check, so it will not lead to inode use-after-free problem, every thing is OK besides this warning. The WARN_ON_ONCE was originally designed for finding inode use-after-free issues in advance, but if we add current dioread_nolock case in, it will become not quite useful, so fix this warning by just remove this check.
====== WARNING: CPU: 7 PID: 1092 at fs/ext4/inode.c:227 ext4_evict_inode+0x875/0xc60 ... RIP: 0010:ext4_evict_inode+0x875/0xc60 ... Call Trace: <TASK> evict+0x11c/0x2b0 iput+0x236/0x3a0 do_unlinkat+0x1b4/0x490 __x64_sys_unlinkat+0x4c/0xb0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7fa933c1115b ======
rm kworker ext4_end_io_end() vfs_unlink() ext4_unlink() ext4_convert_unwritten_io_end_vec() ext4_convert_unwritten_extents() ext4_map_blocks() ext4_ext_map_blocks() ext4_ext_try_to_merge_up() __mark_inode_dirty() check !I_FREEING locked_inode_to_wb_and_lock_list() iput() iput_final() evict() ext4_evict_inode() truncate_inode_pages_final() //wait release io_end inode_io_list_move_locked() ext4_release_io_end() trigger WARN_ON_ONCE()
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 04/21/2026
The vulnerability CVE-2022-50730 addresses a warning condition within the ext4 filesystem implementation of the Linux kernel that occurs during inode eviction when the dioread_nolock feature is active. This issue manifests as a spurious warning message during normal filesystem operations, specifically when attempting to remove files that involve unwritten extents and concurrent writeback operations. The warning originates from the ext4_evict_inode function in the filesystem layer, where the kernel attempts to check the state of inodes during their removal from memory. The problematic scenario emerges when an inode marked for freeing (I_FREEING) undergoes operations that can potentially re-mark it as dirty due to extent conversion processes, creating a race condition between the eviction process and background I/O operations.
The technical flaw stems from an incomplete check within the ext4_evict_inode function that fails to account for a specific race condition involving unwritten extents. When the kernel processes I/O operations for files with dioread_nolock enabled, kworker threads may convert unwritten extents to written ones after writeback operations complete. These conversions can cause extent merging operations that ultimately result in the inode being marked dirty again, even though it was already marked for freeing. The existing warning mechanism in ext4_evict_inode was designed to detect potential use-after-free scenarios by checking the inode's state before eviction, but this check does not properly handle the case where I/O operations can modify the inode's dirty state after the initial freeing flag is set. This creates a false positive warning condition that does not represent an actual system vulnerability but rather an oversight in the warning logic.
The operational impact of this vulnerability is primarily limited to the generation of spurious warning messages in kernel logs, which can create confusion for system administrators monitoring system health. While the warning itself does not cause system instability or data corruption, it does indicate that the kernel's internal consistency checks are being triggered unnecessarily. The race condition described in the vulnerability does not lead to actual use-after-free conditions or memory corruption because the eviction process properly waits for all I/O operations to complete before performing the final inode cleanup. The kernel's design ensures that even though the warning appears, the actual inode management remains safe and correct, as the eviction process includes proper synchronization mechanisms that prevent any real race conditions from manifesting as system failures. This aligns with the ATT&CK framework's concept of system integrity maintenance where the kernel maintains consistent state during critical operations. The vulnerability demonstrates a common pattern in filesystem design where race conditions in concurrent I/O operations can trigger false positives in defensive programming checks, which is categorized under CWE-116 as improper warning handling.
Mitigation strategies for this vulnerability involve simply removing the overly restrictive warning check that does not properly account for the legitimate dioread_nolock scenario. The fix implemented in the kernel removes the specific WARN_ON_ONCE condition that was triggering the false positive, as the underlying functionality remains safe and correct. This approach aligns with the principle of avoiding false positives in system diagnostics that can obscure real issues while maintaining system stability. System administrators should ensure their systems are updated to kernel versions that include this fix, typically those released after the vulnerability was patched. The resolution demonstrates the importance of proper race condition handling in kernel-level filesystem operations and the need for comprehensive testing of concurrent scenarios. This vulnerability also highlights the balance between defensive programming practices and practical system operation, where overly aggressive warning mechanisms can sometimes interfere with normal system behavior rather than enhancing it. The fix maintains the kernel's robustness while eliminating the noise that could mask more serious issues in system monitoring and debugging processes.