A flaw was found in nfs-utils. The fsidd daemon improperly handles input received over its local domain socket by relying on program assertions to verify command arguments. A local user can exploit this vulnerability by sending a malformed request lacking the required arguments to trigger an assertion failure. This causes the daemon to crash, resulting in a Denial of Service (DoS) for filesystem identifier lookup services until restarted.

AIONLYREPORT package: nfs-utils-2.8.3-5.el102 ------ Summary: Local DoS in fsidd via Reachable assert() on Empty Command Arguments: a local unprivileged user can terminate fsidd by sending a malformed command containing only a valid command prefix and trailing space, causing a denial of service for reexport FSID lookups until the daemon is restarted. Requirements to exploit: Local access to a system where fsidd is running for reexport functionality, with the ability to connect to its abstract UNIX domain socket and send a crafted request. Component affected: nfs-utils; support/reexport/fsidd.c; clientcb() Version affected: nfs-utils-2.8.3-5.el102, when fsidd is present and in use for reexport workflows Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Not notified. CVSS: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - 5.5 (MEDIUM) AV:L - Exploitation requires local access to the host and access to the fsidd UNIX socket. AC:L - A single malformed request is sufficient to reach the failing assertion. PR:N - No protocol-level authentication is required before the request is parsed. UI:N - No user interaction is needed once local access is available. S:U - The impact is limited to the vulnerable service itself. C:N - No confidentiality impact was established. I:N - No integrity impact was established. A:H - Successful exploitation aborts fsidd, disrupting FSID lookup handling for reexport use until restart. Impact: Moderate. This issue enables a reliable local denial of service against fsidd, but the impact is limited to availability and depends on a deployment that actually uses fsidd for reexport handling. Under Red Hat's severity guidance, this is more appropriately Moderate than Important because it is not a remote flaw, does not expose confidentiality or integrity, and affects a configuration-dependent service path rather than a broadly reachable default remote attack surface. Embargo: no Reason: This is a local, configuration-dependent denial of service with straightforward mitigation and no demonstrated confidentiality, integrity, or privilege-escalation impact. Acknowledgement: Aisle Research Vulnerability Details: In clientcb(), fsidd parses several commands received over its local socket and relies on assert() to enforce that an argument is present after the command prefix. The following exact checks are reachable from untrusted input: c if (strncmp(buf, "getfsidnum ", strlen("getfsidnum ")) == 0) { char reqpath = buf + strlen("getfsidnum "); ... assert(reqpath < buf + n ); } ... } else if (strncmp(buf, "getorcreatefsidnum ", strlen("getorcreatefsidnum ")) == 0) { char reqpath = buf + strlen("getorcreatefsidnum "); ... assert(reqpath < buf + n ); } ... } else if (strncmp(buf, "getpath ", strlen("getpath ")) == 0) { char reqfsidnum = buf + strlen("getpath "); ... assert(reqfsidnum < buf + n ); } If a request is exactly the command prefix plus a trailing space, such as getfsidnum , then the parsed argument pointer is equal to buf + n and the assertion fails. In an assertion-enabled build, this causes fsidd to abort. The default socket name is defined as an abstract UNIX socket: c #define FSIDSOCKETNAME "@/run/fsid.sock" Based on the available code and report evidence, fsidd processes requests on this socket without checking peer credentials first, so local socket access is sufficient to reach the vulnerable path. The operational effect is a local denial of service against fsidd, which can interrupt reexport FSID lookup handling until the service is restarted. Steps to reproduce: 1. Use a system where fsidd is running for reexport handling. 2. Verify that the service is active. bash systemctl status fsidd 3. Send a malformed command containing a valid command name, trailing space, and no argument to the abstract UNIX seqpacket socket. bash python3 - <<'PY' import socket s = socket.socket(socket.AFUNIX, socket.SOCKSEQPACKET) s.connect("\0/run/fsid.sock") s.sendall(b"getfsidnum ") PY 4. Observe that fsidd terminates with an assertion failure or SIGABRT, for example in the service journal. bash journalctl -u fsidd -n 20 --no-pager 5. Confirm that reexport FSID lookup operations fail until fsidd is restarted. Mitigation: Where reexport support is not required, disable the affected fsidd usage path. Otherwise, restrict untrusted local access to the host and apply input validation so malformed requests are rejected instead of reaching assert(). A service restart policy may reduce outage duration, but it does not prevent the crash condition. Proposed Fix: Replace the reachable assertions with explicit malformed-input handling and return an error to the client. diff diff --git a/support/reexport/fsidd.c b/support/reexport/fsidd.c — a/support/reexport/fsidd.c +++ b/support/reexport/fsidd.c @@ -48,7 +48,12 @@ static void clientcb(evutilsockett cl, short ev, void d) char answer = NULL; bool found; - assert(reqpath < buf + n ); + if (reqpath >= buf + n) { + char answer[] = "- Command failed: Bad input"; + (void)send(cl, answer, strlen(answer), 0); + return; + } @@ -70,7 +75,12 @@ static void clientcb(evutilsockett cl, short ev, void d) char answer = NULL; bool found; - assert(reqpath < buf + n ); + if (reqpath >= buf + n) { + char answer[] = "- Command failed: Bad input"; + (void)send(cl, answer, strlen(answer), 0); + return; + } @@ -94,7 +104,12 @@ static void clientcb(evutilsockett cl, short ev, void d) uint32t fsidnum; bool found; - assert(reqfsidnum < buf + n ); + if (reqfsidnum >= buf + n) { + char answer[] = "- Command failed: Bad input"; + (void)send(cl, answer, strlen(answer), 0); + return; + } ------ This report was generated using AI technology. Always review AI-generated content prior to use

A flaw was found in nfs-utils. An unauthenticated remote attacker can trigger a Denial of Service (DoS) by sending repeated state notification requests to an exposed rpc.statd service. The service fails to properly release memory allocated during callback processing, leading to continuous memory growth. Sustained requests can exhaust system resources, eventually causing the service to degrade or crash.

AIONLYREPORT package: nfs-utils-2.8.3-5.el102 ------ Summary: Memory Leak in nlistfree Leading to Remote Denial of Service: rpc.statd leaks notifylist structures during matching SMNOTIFY callback cleanup, allowing sustained heap growth and eventual denial of service in exposed deployments. Requirements to exploit: The attacker needs network reachability to rpc.statd on a deployment that accepts remote SMNOTIFY requests, at least one monitored host present in rtnl, and a monname or source address that matches that monitored host while alternating state values. Host-based access controls or firewalling can reduce or block reachability in some deployments. Component affected: nfs-utils rpc.statd: utils/statd/notlist.c (nlistfree), remote SMNOTIFY handling in utils/statd/callback.c, callback cleanup in utils/statd/rmtcall.c, and related rtnl cleanup in utils/statd/monitor.c Version affected: nfs-utils-2.8.3-5.el102 when rpc.statd is running, accepts remote SMNOTIFY traffic, and has at least one monitored host entry present Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Not notified. CVSS: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H - 5.9 (MEDIUM) AV:N - The vulnerable entry point is the network-facing SMNOTIFY path in rpc.statd. AC:H - Successful exploitation requires a reachable deployment, a matching monitored host, and sustained state-changing SMNOTIFY traffic. PR:N - The vulnerable code path itself does not require prior authentication. UI:N - No user interaction is required once the service is reachable. S:U - The impact remains within the rpc.statd service boundary. C:N - No confidentiality impact is established by the available evidence. I:N - No integrity impact is established by the available evidence. A:H - Repeated requests can drive unbounded heap growth in rpc.statd and eventually degrade or stop service. Impact: Moderate. Under Red Hat's severity guidance, remote denial of service issues are often Important when they are easy to trigger. Here, exploitation is more constrained because it depends on exposed rpc.statd, an existing monitored-host match, and repeated state toggling, so Moderate is the better fit. Embargo: no Reason: This is a configuration-dependent availability issue with no demonstrated confidentiality or integrity impact, and exposure can be reduced immediately by restricting access to rpc.statd. Acknowledgement: Aisle Research Vulnerability Details: The code shows an ownership mismatch around nlistfree(). The function removes an entry from its list and frees internal strings, but it does not free the notifylist structure itself: c void nlistfree(notifylist head, notifylist entry) { if (head && (head)) nlistremove(head, entry); if (NLMYNAME(entry)) free(NLMYNAME(entry)); if (NLMONNAME(entry)) free(NLMONNAME(entry)); free(entry->dnsname); } Remote SMNOTIFY handling can allocate fresh notifylist objects by cloning a matched monitored-host entry and queueing it on notify whenever the state changes: c for (lp = rtnl ; lp ; lp = lp->next) if (NLSTATE(lp) != argp->state && (statdmatchhostname(argp->monname, lp->dnsname) || statdmatchhostname(ipaddr, lp->dnsname))) { NLSTATE(lp) = argp->state; call = nlistclone(lp); nlistinsert(&notify, call); } Those queued entries are later cleaned only with nlistfree() in the callback processing paths, without a corresponding free() of the structure: c } else { xlog(DGENERAL, "%s: Callback to %s (for %s) succeeded", func, NLMYNAME(lp), NLMONNAME(lp)); } nlistfree(&notify, lp); return 1; } ... } else { xlog(LERROR, "%s: Can't callback %s (%d,%d), giving up", func, NLMYNAME(entry), NLMYPROG(entry), NLMYVERS(entry)); nlistfree(&notify, entry); } } Taken together, these observed code paths create a repeatable allocate-then-leak cycle on the notify queue. The established impact is denial of service through memory growth. The same ownership mismatch also appears in SMUNMON and SMUNMONALL cleanup for rtnl entries, which is why the proposed patch below also adds explicit free(clnt) calls in utils/statd/monitor.c. Remote exploitability remains deployment-dependent because the request must reach rpc.statd and satisfy the monitored-host matching logic. Steps to reproduce: 1. Start rpc.statd in a deployment where it accepts remote SMNOTIFY traffic and has at least one monitored host entry loaded or registered (rtnl != NULL). 2. Identify a monitored host name or source address that satisfies the statdmatchhostname() comparison against lp->dnsname. 3. Send repeated SMNOTIFY RPC requests for that host while alternating state values so NLSTATE(lp) != argp->state remains true. 4. Allow the event loop to process queued entries through processnotifylist() and processreply(). 5. Observe rpc.statd RSS or heap usage growing over time until the service becomes degraded or unavailable. Mitigation: Until a fix is available, restrict network access to rpc.statd to trusted NFS peers only. Where supported by the build and deployment, host-based access controls and firewall rules can block untrusted SMNOTIFY sources. Restarting rpc.statd reclaims leaked memory but does not remove the underlying flaw. Proposed Fix: A minimally scoped correction is to keep nlistfree() ownership semantics unchanged and explicitly free callers that currently leak after cleanup: diff diff --git a/utils/statd/rmtcall.c b/utils/statd/rmtcall.c @@ nlistfree(&notify, lp); + free(lp); return 1; @@ nlistfree(&notify, entry); + free(entry); } } diff --git a/utils/statd/monitor.c b/utils/statd/monitor.c @@ nsmdeletemonitoredhost(clnt->dnsname, monname, myname, 1); nlistfree(&rtnl, clnt); + free(clnt); return (&result); @@ nsmdeletemonitoredhost(clnt->dnsname, monname, myname, 1); nlistfree(&rtnl, clnt); + free(clnt); ++count; clnt = temp; This avoids changing nlistfree() ownership semantics globally and prevents introducing double-free bugs at mixed call sites. ------ This report was generated using AI technology. Always review AI-generated content prior to use

A vulnerability was recently discovered in the rpc.mountd daemon in the nfs-utils package for Linux, that allows a NFSv3 client to escalate the privileges assigned to it in the /etc/exports file at mount time. In particular, it allows the client to access any subdirectory or subtree of an exported directory, regardless of the set file permissions, and regardless of any 'rootsquash' or 'allsquash' attributes that would normally be expected to apply to that client.