CVE-2026-89484: lockd: fix NULL dereference on lockowner allocation failure
In the Linux kernel, the following vulnerability has been resolved:
lockd: fix NULL dereference on lockowner allocation failure
nlmclntlocksinitprivate() installs NLM file lock operations even when nlmclntfindlockowner() fails to allocate a lockowner. nlmclntproc() then returns -ENOMEM, but the VFS still tears down the partially initialized filelock and calls locksreleaseprivate().
That invokes nlmclntlocksreleaseprivate(), which dereferences fl->flu.nfsfl.owner and crashes because the owner was never installed.
Clear flops before attempting to initialize the NLM private state, and install the NLM lock operations only after a lockowner has been allocated successfully.
Affected Software
Event History
Frequently Asked Questions
What condition is required to trigger the crash?
The failure path is triggered when lockd cannot allocate a lockowner during NLM private lock initialization. The subsequent cleanup of a partially initialized file lock dereferences an owner pointer that was never installed.
What is the impact if the condition occurs?
The kernel can crash due to a NULL-pointer dereference in nlmclnt_locks_release_private() during VFS cleanup. The described impact is denial of service through a system crash.
Is there a workaround if the fix cannot be applied immediately?
No workaround is provided in the available data. The fix changes initialization ordering so NLM lock operations are installed only after lockowner allocation succeeds.