CVE-2026-72190 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
ntfs: fix mrec_lock ABBA deadlock in rename
ntfs_file_fsync(), ntfs_dir_fsync() and __ntfs_write_inode() lock an inode's mrec_lock before taking the mrec_lock of its parent directory.
ntfs_rename() takes old_ni->mrec_lock and old_dir_ni->mrec_lock before taking new_ni->mrec_lock for an existing target, or new_dir_ni->mrec_lock for a cross-directory rename. This can deadlock when ntfs_file_fsync() or __ntfs_write_inode() holds the target inode, or when ntfs_dir_fsync() holds a child target directory, while rename() holds the parent directory and waits for the target.
Fix this by locking the existing target inode before taking any parent directory mrec_lock. For cross-directory renames where the target parent is a descendant of the source parent, lock the target parent before the source parent so the directory order matches the child-to-parent order used by ntfs_file_fsync(), ntfs_dir_fsync(), and __ntfs_write_inode().
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability identified in the Linux kernel represents a critical deadlock condition within the ntfs filesystem implementation that can lead to system instability and denial of service. This issue stems from improper locking order during rename operations on ntfs filesystems, creating a classic ABBA deadlock scenario that affects the kernel's ability to manage file system metadata consistently.
The technical flaw manifests in the inconsistent locking hierarchy used by different filesystem operations within the ntfs driver. Specifically, functions ntfs_file_fsync(), ntfs_dir_fsync(), and __ntfs_write_inode() acquire locks in a specific order that first secures an inode's mrec_lock before obtaining its parent directory's mrec_lock. However, the ntfs_rename() function implements a different locking sequence that can result in circular wait conditions when multiple operations attempt to acquire locks in conflicting orders.
The operational impact of this vulnerability extends beyond simple performance degradation to potentially causing complete system hang situations where processes become indefinitely blocked waiting for filesystem resources. When ntfs_file_fsync() or __ntfs_write_inode() holds a target inode's mrec_lock while ntfs_rename() attempts to acquire parent directory locks, or vice versa, the kernel enters a deadlock state that requires manual intervention to resolve.
This vulnerability aligns with CWE-367, which describes the improper locking pattern leading to deadlocks in concurrent systems, and demonstrates characteristics consistent with ATT&CK technique T1489, involving system denial of service through resource exhaustion or lock contention. The fix implemented addresses this by enforcing a consistent locking order that prioritizes acquiring existing target inodes before parent directory locks, ensuring that all operations follow the same hierarchical pattern used by the filesystem's synchronization functions.
For cross-directory rename operations where the target parent directory is a descendant of the source parent directory, the solution implements a specific locking strategy that maintains consistency with the child-to-parent ordering used by ntfs_file_fsync(), ntfs_dir_fsync(), and __ntfs_write_inode(). This approach prevents potential deadlock conditions by ensuring that lock acquisition follows the same logical sequence regardless of the operation being performed. The mitigation strategy specifically addresses the root cause by reordering lock acquisition to prevent circular dependency scenarios while maintaining filesystem consistency and integrity.
The fix represents a defensive programming solution that eliminates race conditions through proper lock ordering, a fundamental principle in concurrent system design that prevents deadlocks by establishing a consistent hierarchy for resource acquisition. This implementation pattern aligns with industry best practices for kernel-level concurrency control and demonstrates the importance of maintaining consistent locking protocols across all filesystem operations to prevent subtle but critical system failures.