Linux hwe edge: In the Linux kernel, the following vulnerability has been resolved: lockd: Avoid hashing uninitialized bytes in nlm4svc_lookup_file() file_hash()… (CVE-2026-74315)
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.
AI Analysis
Technical Summary
The Linux kernel's lockd service had a vulnerability where the file_hash() function hashed uninitialized bytes when processing file handles shorter than LOCKD_FH_HASH_SIZE. This caused the same file handle to hash differently across calls, resulting in missed lock-state lookups. The vulnerability was addressed by zeroing only the tail bytes that file_hash() would consume, ensuring consistent hashing for shorter file handles. Handles equal to or larger than LOCKD_FH_HASH_SIZE were already fully populated and unaffected.
Potential Impact
The inconsistent hashing of file handles could cause lock-state lookups to fail, potentially disrupting the proper functioning of network lock management in NFS environments. This could lead to issues with file locking consistency but does not directly indicate remote code execution or privilege escalation.
Mitigation Recommendations
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.
Linux hwe edge: In the Linux kernel, the following vulnerability has been resolved: lockd: Avoid hashing uninitialized bytes in nlm4svc_lookup_file() file_hash()… (CVE-2026-74315)
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.
CVSS v3.1
Score 9.8critical
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The Linux kernel's lockd service had a vulnerability where the file_hash() function hashed uninitialized bytes when processing file handles shorter than LOCKD_FH_HASH_SIZE. This caused the same file handle to hash differently across calls, resulting in missed lock-state lookups. The vulnerability was addressed by zeroing only the tail bytes that file_hash() would consume, ensuring consistent hashing for shorter file handles. Handles equal to or larger than LOCKD_FH_HASH_SIZE were already fully populated and unaffected.
Potential Impact
The inconsistent hashing of file handles could cause lock-state lookups to fail, potentially disrupting the proper functioning of network lock management in NFS environments. This could lead to issues with file locking consistency but does not directly indicate remote code execution or privilege escalation.
Mitigation Recommendations
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.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-5v8r-fj78-ffg6
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-74315"]
Threat ID: 6a808b6bbf8831d5394f72d4
Added to database: 08/15/2026, 15:53:15 UTC
Last enriched: 08/15/2026, 16:11:32 UTC
Last updated: 09/30/2026, 03:28:30 UTC
Views: 33
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.