CVE-2024-47660 in Linux
Summary
by MITRE • 10/09/2024
In the Linux kernel, the following vulnerability has been resolved:
fsnotify: clear PARENT_WATCHED flags lazily
In some setups directories can have many (usually negative) dentries. Hence __fsnotify_update_child_dentry_flags() function can take a significant amount of time. Since the bulk of this function happens under inode->i_lock this causes a significant contention on the lock when we remove the watch from the directory as the __fsnotify_update_child_dentry_flags() call from fsnotify_recalc_mask() races with __fsnotify_update_child_dentry_flags() calls from __fsnotify_parent() happening on children. This can lead upto softlockup reports reported by users.
Fix the problem by calling fsnotify_update_children_dentry_flags() to set PARENT_WATCHED flags only when parent starts watching children.
When parent stops watching children, clear false positive PARENT_WATCHED flags lazily in __fsnotify_parent() for each accessed child.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 01/17/2026
The vulnerability identified as CVE-2024-47660 affects the Linux kernel's filesystem notification subsystem, specifically within the fsnotify framework that handles file system events and watch mechanisms. This issue manifests when directories contain numerous dentries, particularly negative dentries that represent paths that do not exist. The problem stems from the inefficient handling of PARENT_WATCHED flags during filesystem watch operations, creating significant performance bottlenecks and potential system lockups.
The technical flaw occurs within the __fsnotify_update_child_dentry_flags() function which experiences substantial execution time when processing large numbers of dentries. This function operates under the inode->i_lock protection, creating severe lock contention issues when removing watches from directories. The race condition emerges between fsnotify_recalc_mask() calls that trigger __fsnotify_update_child_dentry_flags() and concurrent __fsnotify_parent() calls that process children, leading to system softlockups as reported by users. This represents a classic concurrency issue where shared resource access patterns create performance degradation and system instability.
The operational impact of this vulnerability extends beyond simple performance degradation to potential system instability and unresponsiveness. When filesystem watch operations occur on directories with many dentries, the locking contention can cause the system to become unresponsive, particularly during high-frequency watch removal operations. The softlockup reports indicate that the kernel's watchdog timer triggers due to the prolonged lock hold times, suggesting that legitimate system operations may be blocked for extended periods. This vulnerability affects systems that rely heavily on filesystem monitoring and watch mechanisms, potentially impacting applications that depend on real-time file system notifications.
The fix implemented addresses this issue by modifying the flag management approach for PARENT_WATCHED flags. Instead of eagerly setting these flags during parent watch initialization, the solution defers this operation until the parent actually begins watching children. When a parent stops watching children, the implementation clears false positive PARENT_WATCHED flags lazily within __fsnotify_parent() during individual child access operations. This approach reduces lock contention by minimizing the scope and duration of critical sections while maintaining the necessary notification semantics. The solution aligns with security best practices for concurrency control and follows established patterns for avoiding lock contention in kernel subsystems.
This vulnerability maps to CWE-691, which addresses inadequate lock management and insufficient lock scope in software systems. The fix demonstrates proper lock discipline by reducing the time spent holding locks and implementing lazy evaluation techniques. From an ATT&CK perspective, this vulnerability could be leveraged in privilege escalation scenarios where an attacker might exploit the system instability to gain elevated privileges or cause denial of service conditions. The mitigation strategy reflects defensive programming principles that prevent resource exhaustion and maintain system responsiveness under load conditions. The solution addresses both the immediate performance bottleneck and the underlying race condition that could lead to system instability, providing a robust fix that maintains the intended functionality while improving system reliability.