Linux Kernel CVE-2026-72355

Requires an active netfs-backed network filesystem mount (AFS, Ceph, CIFS/SMB, or 9p) on the target, plus the ability to generate concurrent I/O that triggers the subrequest retry path while another thread is appending subrequests. Exploitation is limited by being a memory-ordering race (timing-dependent, hard to win deterministically), by the need for local I/O activity against a netfs mount, and by applicability only to kernels ~6.10 and later that use the netfs retry code. The NVD vector's PR:N/AV:N (unauthenticated remote) is not supported by the described local retry-path mechanism and should be independently verified.

The signals conflict sharply and should be reconciled before prioritization. NVD lists CVSS 9.8 with vector AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H (unauthenticated remote full compromise), but this is the standard auto-assigned maximum applied to many Linux kernel commits and does not match the described mechanism: a memory-barrier race in a local retry code path is realistically local-access and high-complexity, not trivially remote. EPSS is very low (0.20% / 10th percentile), there is no CISA KEV listing, and no public exploit identified at time of analysis - all consistent with a low real-world risk. The most probable practical impact is denial of service (crash/oops) or limited information disclosure via a hard-to-win race, not remote code execution. Treat the 9.8 as inflated: verify the true attack vector against the netfs code path before treating this as a critical priority.

An attacker who can drive heavy concurrent read/write I/O against a netfs-backed mount (e.g. a Ceph or CIFS share) forces the kernel into the retry path while simultaneously appending subrequests, attempting to win the memory-ordering race so the retry walk observes a not-yet-initialized subrequest. Success most plausibly yields a kernel crash (DoS) or exposure of stale kernel data. No public proof-of-concept exists at time of analysis, and the race is high-complexity to trigger reliably.