CVE-2026-104045: Sssd: sssd: denial of service via race condition in autofs responder

Published May 18, 2026
·
Updated

A flaw was found in SSSD. A local user can trigger a Denial of Service (DoS) by exploiting a race condition in the autofs responder between asynchronous enumeration completion and map invalidation. By repeatedly sending concurrent map enumeration and invalidation requests, an attacker can cause memory to leak, leading to excessive memory consumption that can disrupt or crash the autofs service.

Other sources

AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: Autofs responder DoS via leaked enumeration contexts after map invalidation race: a race between async enumeration completion and auto.master invalidation can leak autofsenumctx objects and attached results, leading to unbounded memory growth and denial of service in the autofs responder. Requirements to exploit: Local access to a system where the autofs responder is enabled and reachable, plus the ability to issue repeated concurrent SSSAUTOFSGETAUTOMNTENT and SSSAUTOFSSETAUTOMNTENT("auto.master") requests long enough to win the race. Larger maps increase retained memory per leaked context. Component affected: sssd-2.12.0-1.el10, autofs responder, src/responder/autofs/autofssrvcmd.c, primarily autofsorphanmaps() and autofssetentdone(). Version affected: sssd-2.12.0-1.el10 when the autofs responder is enabled 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 - 6.2 (MEDIUM) AV:L - Exploitation requires local access to issue requests to the autofs responder. AC:L - The race can be triggered by repeatedly driving the two request types in parallel; no special precondition beyond timing and sustained requests is established. PR:N - Available evidence supports local triggering without prior privileges in enabled deployments; deployments that add tighter local access controls may reduce this in practice. UI:N - No separate user action is required once the attacker can send the requests. S:U - The impact is within the autofs responder's own security scope. C:N - No confidentiality impact was demonstrated. I:N - No integrity impact was demonstrated. A:H - Repeated triggering can retain enumeration contexts and attached results until memory growth disrupts or exhausts the responder. Impact: Moderate. The issue can cause a local denial of service through memory exhaustion, but no confidentiality or integrity impact is shown, and exploitation depends on the autofs responder being enabled and on repeatedly winning a local race. Under Red Hat's severity guidance, that is more consistent with Moderate than Important. Embargo: no Reason: This is a local availability issue with operational mitigation options and no demonstrated confidentiality, integrity, or system-compromise impact. Acknowledgement: Aisle Research Vulnerability Details: autofssetentsend() creates an enumeration context and inserts it into autofsctx->maps. If SSSAUTOFSSETAUTOMNTENT("auto.master") invalidates maps before the async lookup finishes, autofsorphanmaps() removes the hash entries. When the outstanding lookup later completes, autofssetentdone() unconditionally reparents the now-orphaned enumctx back under maps without restoring the hash entry. The lifetime cleanup path then deletes by key from a table that no longer contains that key, so the leaked context and attached result data remain allocated. Repeating this race can accumulate unbounded memory in sssdautofs. This is consistent with a CWE-401 memory leak triggered through race-dependent behavior. c / src/responder/autofs/autofssrvcmd.c / void autofsorphanmaps(struct autofsctx autofsctx) { sssptrhashdeleteall(autofsctx->maps, false); } ... enumctx = talloczero(memctx, struct autofsenumctx); ... ret = sssptrhashadd(autofsctx->maps, mapname, enumctx, struct autofsenumctx); ... if (strcmp(mapname, "auto.master") == 0) { autofsorphanmaps(autofsctx); } ... state->enumctx->ready = true; / unconditional reparent, even if key was orphaned / tallocsteal(state->autofsctx->maps, state->enumctx); ... sssptrhashdelete(enumctx->table, enumctx->key, false); / timer cleanup path / Steps to reproduce: 1. Run the package with the autofs responder enabled and use a map with many entries so that each leaked enumeration context retains substantial result data. 2. In one loop, repeatedly issue SSSAUTOFSGETAUTOMNTENT for that map to force async enumeration. 3. In a parallel loop, repeatedly issue SSSAUTOFSSETAUTOMNTENT("auto.master") to invalidate maps through autofsorphanmaps(). 4. Sustain both loops for several minutes so enumeration completion regularly races with invalidation. 5. Observe that sssdautofs resident memory grows steadily and does not return to baseline after map lifetimes expire. Debug logging may also show cleanup against missing keys, for example Unable to remove key '%s' from table. Mitigation: Disable the autofs responder where it is not required. Where it must remain enabled, restrict local access to the responder interface to trusted users where deployment policy permits, and avoid repeated invalidation and enumeration cycles against large maps until a fixed build is available. Proposed Fix: Guard the reparenting step in autofssetentdone() so an enumeration context is only stolen under maps if its hash key is still present. If the key was orphaned during the async window, leave the object on the request context so normal teardown can free it. diff diff --git a/src/responder/autofs/autofssrvcmd.c b/src/responder/autofs/autofssrvcmd.c — a/src/responder/autofs/autofssrvcmd.c +++ b/src/responder/autofs/autofssrvcmd.c @@ -351,7 +351,13 @@ static void autofssetentdone(struct teventreq subreq) state->enumctx->ready = true; / Make the enumeration context disappear with maps table. / tallocsteal(state->autofsctx->maps, state->enumctx); + if (sssptrhashhaskey(state->autofsctx->maps, state->enumctx->key)) { + tallocsteal(state->autofsctx->maps, state->enumctx); + } else { + DEBUG(SSSDBGTRACEFUNC, + "Enumeration context for map [%s] was orphaned during async lookup; skipping reparent.\n", + state->enumctx->key); + }

setentnotifydone(&state->enumctx->notifylist); teventreqdone(req); ------ This report was generated using AI technology. Always review AI-generated content prior to use

— Red Hat

Affected Software

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

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Configuration

    Disable the autofs responder where it is not required.

    SSSD autofs responder autofs responder = disabled
  2. Compensating control

    If the autofs responder must remain enabled, restrict local access to its responder interface to trusted users according to deployment policy.

Event History

May 18, 2026
Data Sourced
via Red Hat·03:41 AM
DescriptionSeverityAffected Software
Oct 6, 2026
CVE Published
via MITRE·08:37 PM
Data Sourced
via MITRE·08:37 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·09:17 PM
DescriptionSeverityWeakness

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