CVE-2024-47679 in Linux
Summary
by MITRE • 10/21/2024
In the Linux kernel, the following vulnerability has been resolved:
vfs: fix race between evice_inodes() and find_inode()&iput()
Hi, all
Recently I noticed a bug[1] in btrfs, after digged it into
and I believe it'a race in vfs.
Let's assume there's a inode (ie ino 261) with i_count 1 is called by iput(), and there's a concurrent thread calling generic_shutdown_super().
cpu0: cpu1: iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue;
// return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set
btrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode) // schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput() ->spin_unlock(inode) ->spin_lock(inode) ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict()
Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->i_state & I_CLEAR) statement both within clear_inode() and iput().
To fix the bug, recheck the inode->i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced.
If there is any misunderstanding, please let me know, thanks.
[1]: https://lore.kernel.org/linux-btrfs/[email protected]/
[2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable()
return false when I reproduced the bug.
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 described in CVE-2024-47679 represents a critical race condition within the Linux Virtual File System (VFS) layer that can lead to kernel memory corruption and system instability. This flaw manifests specifically during the interaction between the `device_inodes()` and `find_inode()` functions in conjunction with the `iput()` operation, creating a scenario where concurrent threads can simultaneously attempt to evict the same inode. The vulnerability occurs when an inode with a reference count of one undergoes the `iput()` process while another thread executes `generic_shutdown_super()`, leading to a dangerous overlap in the inode's lifecycle management. The race condition is particularly insidious because it can result in the same inode being processed for eviction by two separate code paths, ultimately triggering kernel assertions and potential system crashes.
The technical root cause of this vulnerability lies in the improper synchronization mechanism during inode state transitions within the VFS subsystem. When the first thread calls `iput()` and decrements the inode's reference count to zero, it enters the `iput_final()` function which performs a series of operations including adding the inode to the LRU list and unlocking the spinlock. However, if a second thread concurrently calls `generic_shutdown_super()` and begins the eviction process, the inode may still appear valid in the hash and superblock lists even though it has been partially processed by the first thread. The second thread's `find_inode()` call locates the inode, checks for freeing flags which are not yet set, and proceeds to increment its reference count before the first thread completes its eviction sequence. This creates a scenario where both threads believe they have exclusive access to the inode and proceed to perform eviction operations simultaneously.
This vulnerability directly maps to CWE-362, which describes a race condition in concurrent programming where two or more threads access shared data concurrently and at least one of the threads modifies the data, leading to unpredictable behavior. The flaw also intersects with ATT&CK technique T1068, which involves exploiting local privileges to gain access to system resources, and T1499, which covers data destruction attacks that can result from system instability caused by kernel-level memory corruption. The vulnerability affects the Linux kernel's memory management subsystem and can be exploited to cause denial of service through system crashes or potentially more severe memory corruption attacks that could lead to privilege escalation. The race condition specifically impacts the inode management mechanism that is fundamental to all file system operations, making it a critical security concern for systems relying on the Linux kernel's VFS layer.
The fix for this vulnerability involves rechecking the inode's reference count after acquiring the inode lock, which prevents the race condition by ensuring that no concurrent threads can proceed with eviction operations on the same inode. This approach reduces the overhead of spinlock operations while maintaining proper synchronization, as the first check is typically valid in most scenarios. The mitigation strategy requires modifications to the inode management code to ensure that after acquiring the inode lock, the system verifies that the reference count has not changed since the initial check. This prevents the scenario where two threads simultaneously believe they have exclusive access to an inode and attempt to evict it. The solution maintains backward compatibility while providing the necessary synchronization to prevent the race condition that could lead to kernel memory corruption and system instability, effectively addressing the core issue identified in the vulnerability report.