Bug 2516922 (CVE-2026-74315) - CVE-2026-74315 kernel: lockd: Avoid hashing uninitialized bytes in nlm4svc_lookup_file()
Summary: CVE-2026-74315 kernel: lockd: Avoid hashing uninitialized bytes in nlm4svc_lo...
Keywords:
Status: NEW
Alias: CVE-2026-74315
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-08-15 06:40 UTC by OSIDB Bzimport
Modified: 2026-08-20 16:41 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-08-15 06:40:32 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.