HIGH
ntfs3 DCompare Blocking
CVE-2026-43245
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
KernelScan AI5.5MEDIUM
01Description
In the Linux kernel, the following vulnerability has been resolved: ntfs: ->d_compare() must not block ... so don't use __getname() there. Switch it (and ntfs_d_hash(), while we are at it) to kmalloc(PATH_MAX, GFP_NOWAIT). Yes, ntfs_d_hash() almost certainly can do with smaller allocations, but let ntfs folks deal with that - keep the allocation size as-is for now. Stop abusing names_cachep in ntfs, period - various uses of that thing in there have nothing to do with pathnames; just use k[mz]alloc() and be done with that. For now let's keep sizes as-in, but AFAICS none of the users actually want PATH_MAX.
02KernelScan AI Analysis
Risk summary
Local users with low privileges can trigger kernel deadlocks or panics when accessing NTFS3 filesystems. The vulnerability causes the kernel to block in atomic context during directory operations, leading to system hangs or crashes that require reboot to recover.
Vulnerability analysis
The root cause is that ntfs_d_compare() and ntfs_d_hash() functions use __getname() which can block (sleep) to allocate memory, but these functions are called in atomic context where blocking is prohibited. The dentry comparison and hashing operations are part of the VFS layer's critical path and must be non-blocking. The fix replaces __getname()/__putname() with kmalloc(PATH_MAX, GFP_NOWAIT)/kfree() to ensure non-blocking allocation, and switches other inappropriate uses of names_cachep to regular k[mz]alloc(). This vulnerability is locally exploitable by any user who can trigger filesystem operations on mounted NTFS3 volumes.
03Fix Versions
| Branch | Fixed in | Patch commit |
|---|---|---|
| 6.12 | 6.12.91 | 1be7ca86ce17 |
| 6.18 | 6.18.16 | 142c444a395f |
| 6.19 | 6.19.6 | fb4b1f969ba0 |
| 6.6 | 6.6.141 | 02ecc0978c45 |
| mainline | 7.0 | ca2a04e84af7 |