CVE-2026-89484: Linux Kernel Use-After-Free Vulnerability

CVE-2026-89484 Overview

CVE-2026-89484 is a NULL pointer dereference vulnerability in the Linux kernel's lockd subsystem. The flaw resides in nlmclnt_locks_init_private(), which installs Network Lock Manager (NLM) file lock operations even when nlmclnt_find_lockowner() fails to allocate a lockowner. When allocation fails, nlmclnt_proc() returns -ENOMEM, but the Virtual File System (VFS) still tears down the partially initialized file_lock and invokes locks_release_private(). That path calls nlmclnt_locks_release_private(), which dereferences fl->fl_u.nfs_fl.owner and crashes because the owner was never installed.

Critical Impact
Local triggering of the memory allocation failure path in NFS/NLM client code can cause a kernel NULL pointer dereference and system crash, resulting in denial of service.

Affected Products

Linux kernel versions containing the vulnerable nlmclnt_locks_init_private() code path in the lockd subsystem
Distributions shipping NFS client support with the affected lockd module
Systems using NFSv3 file locking through the NLM protocol

Discovery Timeline

2026-09-11 - CVE-2026-89484 published to NVD
2026-09-11 - Last updated in NVD database

Technical Details for CVE-2026-89484

Vulnerability Analysis

The vulnerability is a NULL pointer dereference [CWE-476] in the Linux kernel NFS client's lock manager (lockd) code. When a userspace process invokes a file locking operation on an NFS-mounted filesystem, the kernel calls nlmclnt_locks_init_private() to prepare NLM-specific private state on the file_lock structure. This routine installs the NLM file lock operations (fl_ops) before attempting to allocate a lockowner via nlmclnt_find_lockowner().

If lockowner allocation fails under memory pressure, the caller nlmclnt_proc() returns -ENOMEM. However, the VFS layer still calls locks_release_private() on the partially initialized file_lock. That indirection invokes nlmclnt_locks_release_private(), which unconditionally dereferences fl->fl_u.nfs_fl.owner. Because the owner pointer was never populated, the kernel dereferences NULL and crashes.

Root Cause

The root cause is an ordering defect in resource initialization. The code installs the fl_ops pointer before the private state it depends on has been successfully allocated. This creates a window in which cleanup code assumes a valid owner exists when it does not.

Attack Vector

Exploitation requires the ability to trigger file locking operations against an NFS mount and to induce memory allocation failure in nlmclnt_find_lockowner(). A local user with access to an NFS-mounted filesystem can attempt to reach the vulnerable path. The impact is a kernel crash and denial of service on the client system.

No public proof-of-concept code is available. The upstream fix clears fl_ops before initializing NLM private state, and installs the NLM lock operations only after the lockowner has been allocated successfully. See the kernel commits 07adfbb3, 4c7fc129, 51af080c, and d662f7fc for the corrected initialization order.

Detection Methods for CVE-2026-89484

Indicators of Compromise

Kernel oops or panic messages referencing nlmclnt_locks_release_private in the stack trace
NULL pointer dereference faults involving the lockd module on NFS client systems
Unexpected system reboots or hangs on hosts with active NFSv3 mounts under memory pressure

Detection Strategies

Audit installed kernel package versions against distribution advisories referencing the lockd NULL dereference fix
Collect and analyze dmesg and /var/log/messages output for kernel warnings related to nlmclnt_* symbols
Monitor NFS client hosts for repeated crash-restart cycles that correlate with heavy file locking workloads

Monitoring Recommendations

Forward kernel logs and crash dumps to a centralized logging pipeline for symbol-level triage
Alert on kernel panics tagged with NFS or lockd subsystem identifiers
Track memory pressure metrics (available memory, allocation failure counters) on NFS clients to correlate crashes with -ENOMEM conditions

How to Mitigate CVE-2026-89484

Immediate Actions Required

Apply the upstream Linux kernel patches referenced in the stable tree commits and reboot affected systems
Prioritize patching hosts that mount NFSv3 shares and use POSIX file locking
Confirm distribution vendors have shipped a kernel package that includes the fix before production rollout

Patch Information

The fix is available in the mainline and stable Linux kernel trees. Refer to the following commits for the corrective code changes: Kernel Patch 07adfbb3, Kernel Patch 4c7fc129, Kernel Patch 51af080c, and Kernel Patch d662f7fc. The patch reorders initialization so that fl_ops is only installed after nlmclnt_find_lockowner() succeeds.

Workarounds

Where feasible, migrate affected clients to NFSv4, which does not use the NLM sideband protocol for file locking
Reduce memory pressure on NFS client systems to lower the probability of allocation failures in the vulnerable path
Restrict local user access on hosts that cannot be patched immediately to limit exposure to the crash path

bash

# Verify running kernel and check for the fix
uname -r

# Example: rebuild and install a patched kernel (Debian-based)
apt-get update && apt-get install --only-upgrade linux-image-$(uname -r | sed 's/[^-]*-//')

# Reboot to activate the patched kernel
systemctl reboot