CVE-2024-47741 in Linux
Summary
by MITRE • 10/21/2024
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix race setting file private on concurrent lseek using same fd
When doing concurrent lseek(2) system calls against the same file descriptor, using multiple threads belonging to the same process, we have a short time window where a race happens and can result in a memory leak.
The race happens like this:
1) A program opens a file descriptor for a file and then spawns two threads (with the pthreads library for example), lets call them task A and task B;
2) Task A calls lseek with SEEK_DATA or SEEK_HOLE and ends up at file.c:find_desired_extent() while holding a read lock on the inode;
3) At the start of find_desired_extent(), it extracts the file's private_data pointer into a local variable named 'private', which has a value of NULL;
4) Task B also calls lseek with SEEK_DATA or SEEK_HOLE, locks the inode in shared mode and enters file.c:find_desired_extent(), where it also extracts file->private_data into its local variable 'private', which has a NULL value;
5) Because it saw a NULL file private, task A allocates a private structure and assigns to the file structure;
6) Task B also saw a NULL file private so it also allocates its own file private and then assigns it to the same file structure, since both tasks are using the same file descriptor.
At this point we leak the private structure allocated by task A.
Besides the memory leak, there's also the detail that both tasks end up using the same cached state record in the private structure (struct btrfs_file_private::llseek_cached_state), which can result in a use-after-free problem since one task can free it while the other is still using it (only one task took a reference count on it). Also, sharing the cached state is not a good idea since it could result in incorrect results in the future - right now it should not be a problem because it end ups being used only in extent-io-tree.c:count_range_bits() where we do range validation before using the cached state.
Fix this by protecting the private assignment and check of a file while holding the inode's spinlock and keep track of the task that allocated the private, so that it's used only by that task in order to prevent user-after-free issues with the cached state record as well as potentially using it incorrectly in the future.
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-47741 represents a critical race condition within the Linux kernel's btrfs filesystem implementation that arises during concurrent lseek operations on the same file descriptor. This flaw manifests when multiple threads within a single process perform simultaneous lseek system calls against identical file descriptors, creating a temporal window where memory management becomes inconsistent. The vulnerability directly impacts the integrity of file private data structures and introduces potential memory leaks alongside use-after-free conditions that could compromise system stability.
The technical mechanism underlying this race condition occurs within the file.c:find_desired_extent() function where concurrent threads accessing the same file descriptor encounter a critical timing issue. When task A first calls lseek with SEEK_DATA or SEEK_HOLE, it acquires a read lock on the inode and extracts the file's private_data pointer into a local variable named 'private' which initially contains a NULL value. Subsequently, task B performs the same operation on the same file descriptor, also acquiring the inode lock in shared mode and extracting the same NULL private_data value. Both tasks, seeing the NULL value, proceed to allocate their own private structures and assign them to the same file structure, resulting in the memory leak of the structure allocated by task A while task B's allocation overwrites it.
This race condition fundamentally violates the principles of proper concurrent access control and memory management within kernel space operations. The flaw creates a scenario where the btrfs filesystem's private data structure handling becomes inconsistent, leading to memory leaks that accumulate over time and potentially impact system performance. More critically, the shared cached state record within the btrfs_file_private structure poses a significant risk of use-after-free conditions, where one thread may free a cached state record while another thread is still accessing it. The vulnerability is particularly concerning because it involves the struct btrfs_file_private::llseek_cached_state, which is used in extent-io-tree.c:count_range_bits() function where range validation occurs before cached state usage, but the shared access pattern creates potential for incorrect results and system instability.
The fix for this vulnerability requires implementing proper synchronization mechanisms that protect the private assignment and checking of file structures while holding the inode's spinlock, ensuring that only one thread can allocate and assign private data structures at any given time. Additionally, the implementation must track which task allocated the private structure to prevent cross-thread usage of cached state records, thereby eliminating both memory leaks and use-after-free scenarios. This solution aligns with security best practices for concurrent programming and follows established kernel development patterns for handling shared resources in multi-threaded environments. The mitigation approach directly addresses the root cause identified in CWE-362, which describes race conditions in concurrent systems, while also preventing the potential for CWE-416, which covers use-after-free vulnerabilities. The fix ensures that the btrfs filesystem maintains proper memory management under concurrent access conditions and prevents the propagation of inconsistent state information that could lead to system crashes or data corruption.