Linux Kernel CVE-2026-72366

Exploitation is limited to systems running an affected kernel (6.11 through the pre-fix releases) that mount a netfs-backed network filesystem (NFS, AFS, Ceph, CIFS/SMB, 9p) WITH fscache/cachefiles local caching enabled - if caching is not in use, the vulnerable branch is never reached. It further requires local access to generate write operations and hitting the narrow race window during asynchronous cache-object creation. Despite the input CVSS vector's AV:N/PR:N, the described defect is a local kernel caching-path issue with no network-facing trigger; the network/unauthenticated rating is not supported by the description and should be verified with the vendor.

The signals conflict sharply and should be reconciled before prioritization. The input carries a CVSS 3.1 base of 9.8 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H), but that vector is inconsistent with the described defect: this is a local kernel caching-path logic error in netfs, not a network-reachable, unauthenticated RCE - the AV:N/PR:N rating appears to be an automated over-scoring artifact common to bulk Linux kernel CVEs and should not drive urgency. Corroborating this, EPSS is only 0.21% (11th percentile), there is no CISA KEV listing, and no public exploit is identified. Realistically, exposure requires local code execution on a host using a network filesystem with fscache caching enabled, plus hitting the narrow async-object-creation window, so the practical impact is limited cache-state mishandling with a possible information-disclosure edge (per the tag) rather than system compromise. This is a patch-in-normal-maintenance item for most operators - even a mid-sized IT team should apply it during routine kernel updates rather than treating it as an emergency. Bottom line: high nominal CVSS but low real-world risk; verify the vector with the vendor rather than acting on the 9.8 alone.

A local user or process on a host mounting a network filesystem with fscache caching enabled triggers write activity while an fscache cache object is still being created asynchronously, hitting the window where caching state is misjudged. In the worst realistic case this leads to inconsistent cache writes or stale/incorrectly-cached data being served, which the Information Disclosure tag suggests could expose data across the cache boundary. No public proof-of-concept is available, and successful triggering depends on precise timing.