CVE-2026-43245: ntfs: ->d_compare() must not block
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.
Security readout for executives and security teams
Plain-English summary
A Linux NTFS filesystem operation could perform a blocking memory allocation where blocking is unsafe, potentially causing a system availability failure. The supplied assessment rates this high severity, with no stated confidentiality or integrity impact. Systems using affected kernels and NTFS functionality warrant prompt review.
Executive priority
Treat as a high-priority availability issue, especially for critical Linux systems using NTFS. Schedule vendor-supported kernel remediation promptly, but do not characterize it as actively exploited. Validate actual exposure because the provided version ranges and remote attack path are insufficiently explained.
Technical view
The NTFS dentry comparison path used __getname(), which may block. The resolution replaces names_cachep usage with kmalloc or kzalloc and uses kmalloc(PATH_MAX, GFP_NOWAIT) in ntfs_d_compare() and ntfs_d_hash(). The stated impact is availability loss; the bundle does not describe the exact failure mode or triggering prerequisites.
Likely exposure
Potential exposure includes Linux systems running the listed affected releases, particularly where NTFS filesystem operations are used. The supplied version data is ambiguous and includes unusual entries, so administrators should map distribution kernel builds and backports against the cited stable commits rather than relying only on version strings.
Exploitation context
The CVSS assessment states network-accessible, low-complexity, unauthenticated availability impact. However, the supplied technical description does not explain how a remote actor reaches the NTFS path. CISA KEV status is false, and no cited evidence establishes active exploitation or a public exploit.
Researcher notes
The core defect concerns sleeping allocation behavior in d_compare(), with related cleanup in ntfs_d_hash() and other names_cachep users. The source bundle provides multiple stable commits but no CWE, proof of concept, crash trace, attack prerequisites, or clear introduction and fixed-version ranges. The network CVSS vector requires further vendor confirmation.
Mitigation direction
Install a vendor-supported kernel update incorporating the applicable cited stable fix.
Check distribution security guidance for affected build and backport mappings.
Prioritize systems using NTFS or processing NTFS-backed storage.
Follow vendor guidance if an immediate kernel update is unavailable.
Validation and detection
Inventory deployed kernel builds and identify systems using NTFS.
Compare each vendor build against the cited stable fixes or documented backports.
Confirm updated systems booted into the remediated kernel.
Review vendor advisories for revised affected-version or exposure details.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-43245 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
6Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.