CVE-2026-89096: Nfs-utils: nfs-utils: denial of service via memory leak in rpc.statd

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

— Red Hat