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
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.111-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.6-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.111-1~deb12u1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.109 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.50 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.4 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Configuration
Update nlmclnt_locks_init_private() so fl_ops is cleared before attempting NLM private-state initialization and NLM file lock operations are installed only after nlmclnt_find_lockowner() successfully allocates a lockowner.
Linux kernel lockd fl_ops initialization = Clear fl_ops before initializing NLM private state; install NLM lock operations only after a lockowner has been allocated successfully
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.