CVE-2024-47690 in Linux
Summary
by MITRE • 10/21/2024
In the Linux kernel, the following vulnerability has been resolved:
f2fs: get rid of online repaire on corrupted directory
syzbot reports a f2fs bug as below:
kernel BUG at fs/f2fs/inode.c:896! RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Call Trace: evict+0x532/0x950 fs/inode.c:704 dispose_list fs/inode.c:747 [inline]
evict_inodes+0x5f9/0x690 fs/inode.c:797 generic_shutdown_super+0x9d/0x2d0 fs/super.c:627 kill_block_super+0x44/0x90 fs/super.c:1696 kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898 deactivate_locked_super+0xc4/0x130 fs/super.c:473 cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373 task_work_run+0x24f/0x310 kernel/task_work.c:228 ptrace_notify+0x2d2/0x380 kernel/signal.c:2402 ptrace_report_syscall include/linux/ptrace.h:415 [inline]
ptrace_report_syscall_exit include/linux/ptrace.h:477 [inline]
syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173 syscall_exit_to_user_mode_prepare kernel/entry/common.c:200 [inline]
__syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline]
syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218 do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896
Online repaire on corrupted directory in f2fs_lookup() can generate dirty data/meta while racing w/ readonly remount, it may leave dirty inode after filesystem becomes readonly, however, checkpoint() will skips flushing dirty inode in a state of readonly mode, result in above panic.
Let's get rid of online repaire in f2fs_lookup(), and leave the work to fsck.f2fs.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 01/19/2026
The vulnerability identified as CVE-2024-47690 affects the Linux kernel's f2fs filesystem implementation and represents a critical race condition that can lead to kernel panic and system instability. This issue manifests when the filesystem attempts to perform online repair operations on corrupted directories during lookup operations, creating a scenario where dirty data and metadata can be generated while the filesystem is undergoing a readonly remount process. The vulnerability specifically occurs within the f2fs_evict_inode function at line 896 of fs/f2fs/inode.c, where the kernel encounters an unexpected condition that triggers a kernel BUG.
The technical flaw stems from the interaction between online repair mechanisms and the filesystem's readonly state management. During f2fs_lookup() operations, when corrupted directories are encountered, the system attempts to perform online repairs that generate dirty data and metadata. However, this process races with the readonly remount operation, which can leave dirty inodes in the filesystem state. When the filesystem transitions to readonly mode, the checkpoint() function skips flushing these dirty inodes, resulting in an inconsistent state that ultimately causes the kernel to panic. This race condition represents a fundamental flaw in the filesystem's state management and synchronization mechanisms.
The operational impact of this vulnerability extends beyond simple system crashes, as it can compromise data integrity and filesystem consistency. When the kernel panics due to this condition, the system becomes unstable and may require manual intervention to recover. The vulnerability is particularly concerning because it can occur during normal filesystem operations, making it difficult to predict or prevent. The race condition creates a scenario where filesystem corruption can be introduced or exacerbated during the repair process, potentially leading to data loss or corruption that requires manual fsck intervention to resolve.
The mitigation strategy for this vulnerability involves removing the online repair functionality from the f2fs_lookup() function, as recommended in the patch. This approach ensures that repair operations are deferred to the fsck.f2fs utility rather than being performed inline during lookup operations. By eliminating the race condition between online repair and readonly remount operations, the filesystem can maintain consistent state and prevent the kernel panic that occurs when dirty inodes are left unflushed. This remediation aligns with the principle of minimizing inline repair operations in favor of more controlled and predictable maintenance procedures that are better suited for handling filesystem corruption scenarios.
From a cybersecurity perspective, this vulnerability demonstrates the importance of proper synchronization mechanisms in kernel-level filesystem operations and highlights the risks associated with inline repair procedures in concurrent environments. The issue relates to CWE-362, which addresses race conditions in concurrent programming, and can be mapped to ATT&CK technique T1490, which covers data destruction through filesystem manipulation. The vulnerability underscores the need for robust state management and proper handling of filesystem transitions between different operational modes, particularly when dealing with corruption recovery mechanisms that could introduce additional instability into already compromised systems.