Skip to main content
VulnerabilityPublished Updated

CVE-2026-74315: Linux kernel · lockd: Avoid hashing uninitialized bytes in nlm4svc_lookup_file()

Affects Linux kernelSource GCVE Database

0

Not known to be exploited · CVSS 9.8 Critical.

Data as of 26 Oct 2026, 14:05 UTC

CVSS 3.1 base score
9.8Critical
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.5% chance of exploitation in 30 days – higher than 45% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 17 Aug 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

AI-suggested

A fix has been implemented in the Linux kernel to zero the relevant bytes in file handles before hashing, preventing inconsistent hash results. Users should apply the official kernel updates that include this fix. Patch status is not explicitly confirmed in the provided data; check the vendor advisory or Linux kernel mailing lists for the exact patch and update instructions.

Description

In the Linux kernel, the following vulnerability has been resolved: lockd: Avoid hashing uninitialized bytes in nlm4svc_lookup_file() file_hash() digests the first LOCKD_FH_HASH_SIZE bytes of nfs_fh.data when bucketing nlm_files[], independent of fh.size. Commit 3de744ee4e45 ("lockd: Use xdrgen XDR functions for the NLMv4 TEST procedure") set .pc_argzero to zero for the converted procedures and moved file-handle population into nlm4svc_lookup_file(), which copies only xdr_lock->fh.len bytes into lock->fh.data. When an NLMv4 client presents a file handle shorter than LOCKD_FH_HASH_SIZE, bytes fh.len..31 retain whatever the argument buffer held from an earlier request. The same wire handle then hashes to different buckets across calls; nlm_lookup_file() misses the existing nlm_file entry, and lock-state lookups fail. Zero only the tail bytes that file_hash() would otherwise consume. Handles of LOCKD_FH_HASH_SIZE or larger already populate every byte that file_hash() reads.

References

Community reviews

Loading reviews…