Linux Kernel EUVD-2026-45845

Requires local execution on a Linux host that mounts and actively uses a netfslib-backed network filesystem (AFS, Ceph, 9p, cifs/SMB via fscache/netfs), plus concurrent operations that update the inode size at the moment another thread reads ->remote_i_size or ->zero_point. Limiting factors: the attacker/process must already have local code execution and filesystem access; success depends on winning a tight, non-deterministic race window; and the affected code path only exists when netfslib network filesystems are in use - hosts with only local (ext4/xfs, non-netfs) filesystems are not exposed. This contradicts the input CVSS AV:N/PR:N/UI:N, which should not be taken at face value for this local, timing-dependent race.

The signals conflict sharply and should be reconciled before prioritization. The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 9.8) is almost certainly an automated/placeholder score typical of Linux kernel CNA 'has been resolved' advisories and is NOT supported by the description: the flaw is a local kernel data race on internal size fields, not a network-reachable, unauthenticated code-execution path. EPSS agrees with the low real-world urgency - 0.16% probability, 6th percentile - and there is no KEV listing and no POC referenced. Practical impact is limited to torn size reads (stale/inconsistent file size, possible minor information disclosure or misbehavior in netfs-based filesystems), and triggering it requires winning a tight timing window during concurrent size updates. Bottom line: this is a high-CVSS-but-low-real-risk item - patch through normal kernel update cycles, not as an emergency. CONFLICT TO VERIFY: CVSS claims AV:N/PR:N with full C/I/A High, but the description implies local access and a hardening-only fix - treat the 9.8 as unreliable.

A local process performing concurrent operations on a netfslib-backed network filesystem races another thread that is updating the inode's server-reported size, and reads a torn ->remote_i_size/->zero_point value, causing the kernel to act on an inconsistent file size (e.g., exposing stale bytes past the true end or mishandling zeroed regions). No public exploit code exists and the timing window is narrow, making reliable weaponization difficult. The scenario is a local, low-privilege reliability/information-consistency issue rather than a remote compromise.