Linux Kernel EUVD-2026-45641

Exploitation requires the target to be using a netfs-based network filesystem (AFS, Ceph, CIFS/SMB, 9p) and requires driving that filesystem into the subrequest retry path - i.e. subrequests must fail and be re-issued - while concurrent operations mutate stream->subrequests, which is what triggers the unlocked race. Despite the AV:N/PR:N CVSS vector, the flaw is in an internal kernel I/O retry path, so realistic exploitation needs local access to initiate netfs I/O and precise concurrency/timing; it is not a default-config remote-unauthenticated condition. Limiting factors: the affected filesystem type must be in use, the workload must hit failing/retried I/O, the race window is narrow (high complexity), and the most likely outcome is a crash rather than controlled compromise.

The published CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N, 9.8 Critical) is almost certainly an automated over-rating and conflicts with the technical nature of the bug: this is a locking defect in an internal kernel I/O retry path, not a network-facing parser, so genuine unauthenticated remote code execution is not credible. Corroborating signals point to much lower real-world risk: EPSS is 0.15% (5th percentile), the CVE is NOT in CISA KEV, and no POC is referenced - so there is no evidence of active exploitation or a public exploit. Triggering the race requires local activity that drives a netfs-backed filesystem into the retry path under concurrency, which is high-complexity and timing-dependent. The 'Information Disclosure' tag plus the list-corruption nature suggests the realistic worst case is a kernel crash (DoS) or potential memory disclosure/corruption, not turnkey RCE. Net assessment: treat as a standard kernel hardening fix to be picked up via normal stable-kernel updates, not an emergency - the CVSS network vector should be verified against the local/config-dependent reality before prioritizing.

A local user with the ability to drive a netfs-backed mount (e.g. Ceph, CIFS/SMB, AFS, 9p) generates I/O that repeatedly fails and enters the retry path while concurrently issuing more requests, racing the unlocked insertion into stream->subrequests to corrupt the list. The result is most plausibly a kernel panic (denial of service) or leaked/corrupted memory rather than reliable code execution. No public POC is referenced, and the timing-sensitive, high-complexity nature makes weaponization difficult.