REDHAT-BUG-2478864: Medium severity redhat/sssd vulnerability

Published May 18, 2026
·
Updated

AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: Unbounded NSS Negative Cache Growth Can Cause Local DoS (Memory Exhaustion): an unprivileged local user can trigger large numbers of distinct negative NSS lookups and drive application-level unbounded growth of the in-memory negative cache, potentially exhausting responder memory and disrupting local name-service availability. Requirements to exploit: Unprivileged local access on a system where the sssd NSS responder is active, the responder socket is reachable by local users, and entrynegativetimeout is non-zero (default 15). The attacker must be able to trigger many distinct NSS misses through normal lookup paths. The available evidence does not establish remote exploitability by default. Component affected: sssd-2.12.0-1.el10 NSS responder negative cache in src/responder/common/negcache.c (sssncacheinit(), sssncachecheckstr(), sssncachesetstr()), with local reachability through src/responder/nss/nsssrv.c Version affected: sssd-2.12.0-1.el10 when the NSS responder is active and entrynegativetimeout is non-zero (default 15) 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:L/UI:N/S:U/C:N/I:N/A:H - 5.5 (MEDIUM) AV:L - The established attack path requires local access to issue NSS lookups on the host. AC:L - Repeated distinct nonexistent lookups are sufficient; no race or special conditions are required. PR:L - The demonstrated exploit requires an unprivileged local execution context or local account on the system. UI:N - No victim interaction is needed. S:U - The impact remains within the vulnerable component's security scope. C:N - No confidentiality impact is established by the available evidence. I:N - No integrity impact is established by the available evidence. A:H - Responder memory can grow until service becomes unstable or the process is OOM-killed. Impact: Moderate. The established outcome is a practical local denial of service against the NSS responder, not remote compromise, privilege escalation, or data exposure. Under Red Hat's severity guidance, that is more than Low because it can materially disrupt host functionality in active NSS deployments, but below Important because the supported attack is local-only and availability-focused. Embargo: no Reason: The available evidence supports a local denial of service with operational mitigations and no evidence of remote compromise, confidentiality loss, or privilege escalation. This class of issue can usually be fixed and disclosed without a prolonged embargo. Acknowledgement: Aisle Research Vulnerability Details: In src/responder/common/negcache.c, the negative cache is created as an in-memory TDB and expired entries are only removed lazily when the same key is checked again: c ctx->tdb = tdbopen("memcache", 0, TDBINTERNAL, ORDWR|OCREAT, 0); ... if (expired) { / expired, remove and return no entry / tdbdelete(ctx->tdb, key); ret = ENOENT; } New negative entries are inserted through tdbstore() with no application-level global size or entry bound shown in this path: c ret = tdbstore(ctx->tdb, key, data, TDBREPLACE); Non-permanent negative caching is enabled by default. In src/responder/common/respondercommon.c, the responder reads entrynegativetimeout with a default of 15: c ret = confdbgetint(cdb, CONFDBNSSCONFENTRY, CONFDBNSSENTRYNEGTIMEOUT, 15, &tmpvalue); Local reachability is realistic when the NSS responder is enabled, because the responder defines a public socket umask: c / Public sockets must be readable and writable by anybody on the system. So we set umask to 0111. / #define SCKTRSPUMASK 0111

Based on the available code and reproduction, many distinct nonexistent lookups can accumulate in memory even though each entry has a timeout, because unique keys are not revisited and therefore do not trigger lazy expiry removal. The supported attack path is through successful "not found" handling in the normal cache-request flow, not through malformed packet delivery. There is an operational clear path for the negative cache, but that is a cleanup mechanism rather than a preventive limit. Steps to reproduce: 1. Ensure the system is using the sssd NSS responder and that entrynegativetimeout is non-zero. 2. Monitor responder memory usage, for example: bash watch -n1 'ps -o pid,rss,cmd -C sssdnss' 3. As an unprivileged local user, generate a large number of distinct negative NSS lookups: bash for i in $(seq 1 500000); do getent passwd nosuchuser$i >/dev/null; done 4. Observe steady RSS growth in sssdnss during and after the run. 5. As a control, clear the negative cache through the existing operational path or send SIGHUP to the monitor; this should remove the accumulated negative-cache state and typically relieve the observed memory pressure. Mitigation: Set entrynegativetimeout = 0 to disable non-permanent negative-cache insertions. This reduces exposure but increases backend lookup traffic.

Use the existing negative-cache clear path or restart the responder if memory growth is observed.

Restrict untrusted local users on systems where the NSS responder is exposed and this behavior would be materially disruptive.

Proposed Fix: A minimal hardening approach is to opportunistically prune expired entries before insertion and reject new inserts once a configured maximum entry count is reached. diff diff --git a/src/responder/common/negcache.c b/src/responder/common/negcache.c ... — a/src/responder/common/negcache.c +++ b/src/responder/common/negcache.c @@ -41,10 +41,15 @@ #define NCDOMAINACCTLOCATEPREFIX NCENTRYPREFIX"DOMLOCATE" #define NCDOMAINACCTLOCATETYPEPREFIX NCENTRYPREFIX"DOMLOCATETYPE" +#define NCACHEDEFAULTMAXENTRIES 20000 + struct sssncctx { struct tdbcontext tdb; uint32t timeout; + uint32t maxentries; }; +struct ncacheprunestate { timet now; uint32t alive; }; + typedef int (ncachesetbynamefnt)(struct sssncctx , bool, const char , const char ); @@ -79,6 +84,7 @@ int sssncacheinit(TALLOCCTX memctx, uint32t timeout, if (!ctx->tdb) return errno; ctx->timeout = timeout; + ctx->maxentries = NCACHEDEFAULTMAXENTRIES; ctx = ctx; return EOK; @@ -146,6 +152,36 @@ done: return ret; } +static int ncachepruneexpired(struct tdbcontext tdb, + TDBDATA key, TDBDATA data, void pvt) +{ + struct ncacheprunestate st = tallocgettype(pvt, struct ncacheprunestate); + unsigned long long ts; + char ep = NULL; + + errno = 0; + ts = strtoull((const char )data.dptr, &ep, 10); + if (errno != 0 || ep != '\0') { + return tdbdelete(tdb, key); + } + + if (ts != 0 && ts < (unsigned long long)st->now) { + return tdbdelete(tdb, key); + } + + st->alive++; + return 0; +} + static int sssncachesetstr(struct sssncctx ctx, char str, bool permanent) { + struct ncacheprunestate st = { 0 }; TDBDATA key; TDBDATA data; @@ -167,6 +203,18 @@ static int sssncachesetstr(struct sssncctx ctx, char str, bool permanent) } if (!timest) return ENOMEM; + st.now = time(NULL); + if (tdbtraverse(ctx->tdb, ncachepruneexpired, &st) < 0) { + return EIO; + } + if (st.alive >= ctx->maxentries) { + DEBUG(SSSDBGMINORFAILURE, + "Negative cache limit reached (%u), dropping [%s]\n", + ctx->maxentries, str); + tallocfree(timest); + return ENOSPC; + } + ret = stringtotdbdata(timest, &data); if (ret != EOK) goto done; ------ This report was generated using AI technology. Always review AI-generated content prior to use

Affected Software

1 affected component
redhat/sssd=2.12.0-1.el10

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Configuration

    Set entry_negative_timeout to 0 to disable non-permanent negative caching; this reduces exposure but increases backend lookup traffic.

    sssd NSS responder entry_negative_timeout = 0
  2. Compensating control

    Restrict untrusted local users on systems where the NSS responder is active.

  3. Compensating control

    Monitor sssd_nss responder memory usage, for example with `watch -n1 'ps -o pid,rss,cmd -C sssd_nss'`, and observe for steady RSS growth during and after testing.

  4. Operational

    Clear the negative-cache state through the existing operational clear path, or restart the responder; this removes accumulated negative-cache entries and typically relieves memory pressure.

Event History

May 18, 2026
Data Sourced
via Red Hat·03:47 AM
DescriptionSeverityAffected Software

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203