CVE-2022-50730
Ext4 Warning Suppression for Race Condition During Inode Eviction
Publication date: 2025-12-24
Last updated on: 2025-12-24
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | linux_kernel | * |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-UNKNOWN |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability involves a warning in the Linux kernel's ext4 filesystem code when evicting an inode with the dioread_nolock option. During eviction, a race condition can occur where unwritten extents are converted to written extents by a background worker after writeback of newly allocated dirty blocks. This can cause the inode to be marked dirty again even after it has been marked as freeing (I_FREEING). The original warning (WARN_ON_ONCE) was intended to detect inode use-after-free issues, but this race condition causes the warning to trigger incorrectly. The fix removes this warning check to avoid false positives, as the actual inode use-after-free problem does not occur due to waiting for all extent conversions to finish before the check.
How can this vulnerability impact me? :
The impact of this vulnerability is limited to a warning message being triggered in the kernel logs during inode eviction under certain conditions. It does not lead to inode use-after-free or memory corruption, so it does not cause system crashes or data corruption. Essentially, it is a false positive warning that has been silenced to avoid confusion and unnecessary concern.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability manifests as a warning in the Linux kernel logs related to ext4 inode eviction, specifically a WARN_ON_ONCE message at fs/ext4/inode.c:227 in ext4_evict_inode. To detect it, you can monitor your system logs (e.g., using dmesg or journalctl) for warnings containing 'ext4_evict_inode' or related ext4 warnings. Example commands: 'dmesg | grep ext4_evict_inode' or 'journalctl -k | grep ext4_evict_inode'.
What immediate steps should I take to mitigate this vulnerability?
Since this issue is a warning without leading to inode use-after-free or system instability, immediate mitigation involves updating the Linux kernel to a version where this warning has been fixed by removing the problematic check in ext4_evict_inode. Until then, monitoring logs for the warning and avoiding workloads that heavily trigger ext4 inode eviction may reduce occurrences.