<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-28T23:38:52.446759+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/cve-2026-93231</id>
    <title>CVE-2026-93231 — lockd: fix swapped arguments in nlmsvc_match_ip()</title>
    <updated>2026-09-28T23:38:52.450159+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Linux</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>lockd: fix swapped arguments in nlmsvc_match_ip()</p>
<p>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:</p>
<p>nlm_traverse_files(server_addr, nlmsvc_match_ip, NULL);</p>
<p>The match callback is later invoked from nlm_traverse_locks() as:</p>
<p>match(lockhost, host);</p>
<p>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.</p>
<p>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"):</p>
<p>return rpc_cmp_addr(nlm_srcaddr(host), datap);</p>
<p>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.</p>
<p>Swap the arguments so the lock owner's source address is compared
against the requested server add…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2026-93231"/>
  </entry>
</feed>
