Description
In the Linux kernel, the following vulnerability has been resolved:

lockd: fix swapped arguments in nlmsvc_match_ip()

When releasing locks by server IP address via /proc/fs/nfsd/unlock_ip,
nlmsvc_unlock_all_by_ip() calls nlm_traverse_files() with the server
sockaddr as the opaque @data argument:

nlm_traverse_files(server_addr, nlmsvc_match_ip, NULL);

The match callback is later invoked from nlm_traverse_locks() as:

match(lockhost, host);

where the first argument is the nlm_host that owns the lock, and the
second argument is the @data that was originally passed down (here the
server sockaddr). This is the convention every other match callback
relies on (nlmsvc_mark_host(), nlmsvc_same_host(), nlmsvc_is_client()):
arg1 is the real nlm_host, arg2 is the caller-supplied reference value.

nlmsvc_match_ip() has had these two arguments reversed ever since the
unlock-by-IP feature was introduced in commit 4373ea84c84d ("lockd:
unlock lockd locks associated with a given server ip"):

return rpc_cmp_addr(nlm_srcaddr(host), datap);

Here @host is actually the server sockaddr, so nlm_srcaddr(host)
dereferences a struct sockaddr as a struct nlm_host and reads garbage
at the offset of h_srcaddr; meanwhile @datap is actually the lock
owner's nlm_host but is compared as a sockaddr. As a result the
comparison practically never matches and locks are not released for the
requested IP.

Swap the arguments so the lock owner's source address is compared
against the requested server address:

return rpc_cmp_addr(nlm_srcaddr(datap), (struct sockaddr *)host);

[ cel: fix the misleading typedef parameter names too ]
Published: 2026-09-24
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: Denial of Service
Action: Update Kernel
AI Analysis

Impact

In the Linux kernel, the function nlmsvc_match_ip() was comparing the wrong arguments when attempting to unlock NFS locks by server IP via /proc/fs/nfsd/unlock_ip. The server sockaddr was mistakenly compared against the lock owner's nlm_host instead of vice versa, so the comparison never matched and locks were not released for the requested IP. This logical bug allows locks to persist indefinitely, potentially blocking resources, causing service disruptions, and making NFS operations unreliable for clients that rely on timely lock release.

Affected Systems

The issue affects all Linux kernel versions before the fix commit (0d72e78c9d38d5). It applies to every kernel that implements the lockd unlock‑by‑IP feature in the NFS server. Users running any kernel older than the commit that swaps the arguments in nlmsvc_match_ip() are impacted.

Risk and Exploitability

The CVSS score is not available, and the EPSS score is not reported. The vulnerability is not listed in CISA's KEV catalog, suggesting no documented exploitation. It is inferred that any entity that can cause the NFS server to attempt an unlock for a specific IP address might be able to trigger this logic error. Because the flaw resides in kernel code, it is inferred that local or root privileges may be required to fully trigger the vulnerability, which could result in a denial‑of‑service condition by preventing lock release.

Generated by OpenCVE AI on September 25, 2026 at 11:59 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply the kernel patch that swaps the arguments in nlmsvc_match_ip() (commit 0d72e78c9d38d5 or later)
  • Restart the NFS service to clear any locks that have become stuck
  • Verify that locks are successfully released for the target IP using system monitoring tools such as nfsstat -s

Generated by OpenCVE AI on September 25, 2026 at 11:59 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sat, 03 Oct 2026 11:15:00 +0000

Type Values Removed Values Added
References

Fri, 25 Sep 2026 12:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-687

Thu, 24 Sep 2026 15:30:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: lockd: fix swapped arguments in nlmsvc_match_ip() When releasing locks by server IP address via /proc/fs/nfsd/unlock_ip, nlmsvc_unlock_all_by_ip() calls nlm_traverse_files() with the server sockaddr as the opaque @data argument: nlm_traverse_files(server_addr, nlmsvc_match_ip, NULL); The match callback is later invoked from nlm_traverse_locks() as: match(lockhost, host); where the first argument is the nlm_host that owns the lock, and the second argument is the @data that was originally passed down (here the server sockaddr). This is the convention every other match callback relies on (nlmsvc_mark_host(), nlmsvc_same_host(), nlmsvc_is_client()): arg1 is the real nlm_host, arg2 is the caller-supplied reference value. nlmsvc_match_ip() has had these two arguments reversed ever since the unlock-by-IP feature was introduced in commit 4373ea84c84d ("lockd: unlock lockd locks associated with a given server ip"): return rpc_cmp_addr(nlm_srcaddr(host), datap); Here @host is actually the server sockaddr, so nlm_srcaddr(host) dereferences a struct sockaddr as a struct nlm_host and reads garbage at the offset of h_srcaddr; meanwhile @datap is actually the lock owner's nlm_host but is compared as a sockaddr. As a result the comparison practically never matches and locks are not released for the requested IP. Swap the arguments so the lock owner's source address is compared against the requested server address: return rpc_cmp_addr(nlm_srcaddr(datap), (struct sockaddr *)host); [ cel: fix the misleading typedef parameter names too ]
Title lockd: fix swapped arguments in nlmsvc_match_ip()
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-10-03T10:57:07.947Z

Reserved: 2026-09-17T16:02:15.095Z

Link: CVE-2026-93231

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-24T16:17:18.637

Modified: 2026-10-03T11:17:46.677

Link: CVE-2026-93231

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-25T12:00:15Z

Weaknesses
  • CWE-687

    Function Call With Incorrectly Specified Argument Value