CVE-2026-93231 in Linux
Summary
by MITRE • 09/24/2026
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 ]
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/24/2026
The vulnerability identified in the Linux kernel involves a critical argument swap within the lockd subsystem, specifically affecting the nlmsvc_match_ip function. This flaw was introduced during the implementation of the unlock-by-IP feature and persists as a logical error that prevents the proper release of Network File System locks associated with specific server IP addresses. The issue resides in how callbacks are invoked through the nlm_traverse_files mechanism when processing requests to unlock files via /proc/fs/nfsd/unlock_ip. When this operation is triggered, nlmsvc_unlock_all_by_ip passes a pointer to the target server's sockaddr structure as the opaque data argument into nlm_traverse_files. This callback system relies on a strict convention where the first argument represents the actual lock-holding entity and the second argument serves as the reference value for comparison. However, nlmsvc_match_ip incorrectly reverses these parameters during its internal logic, leading to fundamental type mismatches and failed comparisons that effectively disable the intended security control mechanism.
From a technical perspective, the core of this vulnerability lies in the misinterpretation of data structures due to swapped function arguments. The match callback is invoked by nlm_traverse_locks with two distinct pointers: one pointing to an nlm_host structure representing the lock owner and another pointing to the caller-supplied reference value, which in this context is the server sockaddr intended for matching. Inside nlmsvc_match_ip, the code erroneously treats the first argument as a sockaddr and the second as an nlm_host. Consequently, when executing rpc_cmp_addr(nlm_srcaddr(host), datap), the function attempts to dereference the host pointer as if it were a struct sockaddr while simultaneously treating the data pointer as such for comparison purposes. Since these pointers actually point to different structures with incompatible memory layouts, accessing fields like h_srcaddr on an nlm_host object results in reading garbage values from unrelated memory offsets. This type confusion ensures that the address comparison practically never succeeds, rendering the lock release operation ineffective regardless of whether a valid match exists.
The operational impact of this vulnerability is significant for systems relying on NFS locking mechanisms to manage file access consistency and security. Because nlmsvc_match_ip fails to correctly identify locks associated with the specified server IP, administrators cannot reliably revoke or reset these locks through standard interfaces. This leads to stale lock entries persisting in the kernel state even after explicit unlock commands are issued via /proc/fs/nfsd/unlock_ip. In environments where strict access control and resource cleanup are required, such as high-availability clusters or systems subject to frequent IP address changes, this defect can result in denied service for legitimate clients holding locks that should have been released. Furthermore, the inability to clear these locks may contribute to memory leaks within the kernel's lock daemon subsystem over extended periods of operation, potentially degrading system performance and stability.
This flaw is categorized under CWE-841 Improper Enforcement of Behavioral Workflow because it represents a failure in enforcing the correct sequence or logic required for secure state management. The vulnerability allows an attacker with access to the unlock interface to bypass intended restrictions by exploiting the fact that locks remain active despite explicit revocation attempts. In terms of MITRE ATT&CK, this relates to techniques involving persistence and resource hijacking, as malicious actors could potentially maintain unauthorized file locks to disrupt operations or hide activities from standard monitoring tools that rely on lock state integrity. The lack of proper validation in argument handling creates a gap in the defense-in-depth strategy for NFS services.
Mitigation strategies primarily involve applying kernel patches that correct the parameter order within nlmsvc_match_ip and updating associated typedefs to prevent future confusion among developers. System administrators should ensure their Linux kernels are updated to versions where this specific commit has been merged, as upstream fixes typically address such logical errors promptly. Additionally, monitoring /proc/fs/nfsd/lock for anomalous lock counts or unexpected persistence of locks after unlock operations can help detect instances where the vulnerability is being exploited in unpatched environments. Regular auditing of NFS configurations and limiting access to sensitive proc filesystem interfaces further reduces the attack surface associated with this type of logic error.