Linux Kernel CVE-2026-74315

Requires that the target run a Linux kernel containing commit 3de744ee4e45 with the in-kernel lockd/NLMv4 service enabled and NFS exports reachable by the attacker, and requires the attacker to act as an NLM client sending a file handle strictly shorter than LOCKD_FH_HASH_SIZE (32 bytes) - handles of 32 bytes or more are unaffected because they fully populate the hashed region. Exploitation is limited by the need for network reachability to the lockd RPC service, by the requirement that lock lookups fail only when residual buffer bytes differ between requests (a timing/state-dependent condition, not deterministic), and by the fact that the impact is confined to advisory-lock correctness rather than memory disclosure or code execution.

The NVD CVSS of 9.8 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H) is an automated, boilerplate maximum that is not supported by the technical description and should be treated as inflated. The description describes a correctness bug - lock lookups miss existing entries - not remote code execution or attacker-readable memory: the uninitialized bytes influence only an internal hash bucket and are never returned to the client, so the 'Information Disclosure' tag overstates real confidentiality impact. Corroborating signals point to low real-world risk: EPSS is 0.15% (5th percentile), there is no KEV listing and no public PoC, and exploitation would produce inconsistent/failed advisory locking rather than a security compromise. The primary discrepancy to flag: CVSS claims C:H/I:H/A:H with AC:L, but the flaw is a heisenbug whose behavior depends on residual buffer content from earlier requests, making reliable, targeted triggering non-trivial and the practical impact limited to locking availability/correctness - verify severity against the kernel maintainers' own assessment rather than the NVD auto-score.

An NLMv4 client on the network sends a lock request (e.g., TEST/LOCK) carrying an NFS file handle shorter than 32 bytes to a vulnerable lockd server; the trailing uninitialized handle bytes vary with whatever the previous request left in the buffer, so repeated operations on the same file hash to different buckets and the server fails to find the existing lock record. The realistic outcome is broken or inconsistent advisory locking (stale/duplicate lock state) rather than code execution or data theft. No public exploit code exists, and reliable triggering is complicated by dependence on residual buffer contents.