CVE-2026-104031: Sssd: sssd: denial of service via memory exhaustion in autofs responder

Published May 18, 2026
·
Updated

A flaw was found in SSSD. In configurations where the autofs responder service is enabled, memory allocated during successful request processing is not released until the client connection terminates. A local attacker can exploit this vulnerability by maintaining an open connection and repeatedly submitting valid requests, leading to memory exhaustion and a Denial of Service (DoS).

Other sources

AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: Local DoS in Autofs responder due to per-request autofscmdctx lifetime bug (and pinned enum references): successful autofs responder requests can retain per-request state until connection close, allowing local memory exhaustion when the autofs responder/socket is enabled and reachable. Requirements to exploit: A local actor must be able to reach the autofs responder/socket in an affected deployment, keep a client connection open, and send a large number of valid autofs requests that complete successfully. Component affected: sssd-2.12.0-1.el10 Autofs responder, primarily src/responder/autofs/autofssrvcmd.c (sssautofscmdsetautomntentdone, sssautofscmdgetautomntentdone, sssautofscmdgetautomntbynamedone) and src/responder/common/respondercmd.c (ssscmddone) Version affected: sssd-2.12.0-1.el10, when the autofs responder/socket is enabled and reachable by a local user 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 - Exploitation requires local access to a reachable autofs responder/socket. AC:L - The issue can be triggered by repeatedly sending valid successful requests over one connection. PR:L - The attacker must be able to use the local autofs responder in an affected deployment; the available evidence does not establish anonymous reachability for all configurations. UI:N - No user interaction is required once the attacker can reach the responder. S:U - The impact remains within the SSSD responder's security scope. C:N - No confidentiality impact is shown by the available evidence. I:N - No integrity impact is shown by the available evidence. A:H - Repeated retained request contexts can exhaust responder memory and disrupt service. Impact: Moderate. This is an availability issue with a credible memory-exhaustion outcome, but the demonstrated attack is local and depends on the autofs responder/socket being enabled and reachable. Under Red Hat's severity guidance, that is better classified as Moderate than Important because the report does not establish remote reachability, privilege escalation, or broader system compromise. Embargo: no Reason: The demonstrated impact is local, availability-only, and configuration-dependent, and practical mitigation exists by disabling or restricting access to the autofs responder until a fix is shipped. Acknowledgement: Aisle Research Vulnerability Details: autofscmdctx is allocated per request as a child of the long-lived client connection context (cmdctx = talloczero(clictx, struct autofscmdctx);). In the async success path, the responder writes the reply and then finishes with ssscmddone(cmdctx->clictx, NULL): c sssautofscmdgetautomntentdone(struct teventreq req) { struct autofsenumctx enumctx; struct autofscmdctx cmdctx; errnot ret; cmdctx = teventreqcallbackdata(req, struct autofscmdctx); ret = autofssetentrecv(cmdctx, req, &enumctx); talloczfree(req); if (ret != EOK) { autofscmddone(cmdctx, ret); return; } ret = autofswritegetautomntentoutput(cmdctx->clictx, enumctx, cmdctx->cursor, cmdctx->maxentries); if (ret != EOK) { DEBUG(SSSDBGCRITFAILURE, "Unable to create reply packet " "[%d]: %s\n", ret, sssstrerror(ret)); autofscmddone(cmdctx, ret); return; } ssscmddone(cmdctx->clictx, NULL); } ssscmddone() only frees the explicit freectx argument: c void ssscmddone(struct clictx cctx, void freectx) { / now that the packet is in place, unlock queue making the event writable / TEVENTFDWRITEABLE(cctx->cfde);

/ free all request related data through the talloc hierarchy / tallocfree(freectx); } The same success-path pattern is present in sssautofscmdsetautomntentdone and sssautofscmdgetautomntbynamedone. By contrast, handled error paths use autofscmddone(cmdctx, ret), which frees cmdctx, so the retained lifetime appears limited to successful asynchronous completions. In the GETAUTOMNTENT path, autofssetentrecv(cmdctx, req, &enumctx) additionally does enumctx = tallocreference(memctx, state->enumctx);; because cmdctx is used as memctx, leaked request contexts can also retain that extra reference. Repeating successful requests over one long-lived connection can therefore grow responder memory until the connection is closed or the process is restarted. Steps to reproduce: 1. Run SSSD with the autofs responder enabled and ensure the autofs responder/socket is reachable in the target deployment. 2. Open one persistent client connection to the autofs responder. 3. Over that same connection, send a high volume of valid successful SETAUTOMNTENT, GETAUTOMNTENT, or GETAUTOMNTBYNAME requests. 4. Observe responder RSS or heap usage while the connection remains open. 5. Confirm that memory usage grows with request count and does not return to baseline until the connection is closed or the process is restarted. 6. Optionally apply the three-line patch below and repeat the same request pattern; the per-request accumulation should stop. Mitigation: If the autofs responder is not required, disable it. Otherwise, restrict access to the autofs responder/socket to trusted local clients only until a fixed package is available. Closing long-lived client connections or restarting the responder reclaims retained objects, but that is operational containment rather than a complete fix. Proposed Fix: Pass cmdctx instead of NULL to ssscmddone() in the three async success callbacks so the per-request context is released after successful completion. 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 @@ -517,7 +517,7 @@ sssautofscmdsetautomntentdone(struct teventreq req) ssscmddone(cmdctx->clictx, NULL); + ssscmddone(cmdctx->clictx, cmdctx); @@ -727,7 +727,7 @@ sssautofscmdgetautomntentdone(struct teventreq req)

ssscmddone(cmdctx->clictx, NULL); + ssscmddone(cmdctx->clictx, cmdctx); @@ -927,7 +927,7 @@ sssautofscmdgetautomntbynamedone(struct teventreq req)

ssscmddone(cmdctx->clictx, NULL); + ssscmddone(cmdctx->clictx, cmdctx);

------ 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 if it is not required.

    SSSD autofs responder autofs responder service = disabled
  2. Compensating control

    Restrict access to the autofs responder/socket to trusted local clients until a fix is available.

  3. Compensating control

    Apply the proposed source change in src/responder/autofs/autofssrv_cmd.c: in the three async success callbacks for SETAUTOMNTENT, GETAUTOMNTENT, and GETAUTOMNTBYNAME, pass cmd_ctx instead of NULL to sss_cmd_done(), so the per-request context is released.

  4. Operational

    Close long-lived autofs client connections or restart the responder to reclaim retained request objects.

Event History

May 18, 2026
Data Sourced
via Red Hat·04:05 AM
DescriptionSeverityAffected Software
Oct 6, 2026
CVE Published
via MITRE·12:10 AM
Data Sourced
via MITRE·12:10 AM
DescriptionSeverityWeakness
Data Sourced
via NVD·01:16 AM
DescriptionSeverityWeakness

Frequently Asked Questions

1

Which deployments are exposed to this denial-of-service condition?

Deployments are exposed when the SSSD autofs responder service is enabled and its socket is reachable by a local actor. The affected component identified in the report is the Autofs responder in sssd-2.12.0-1.el10.

2

What does an attacker need to do to trigger the issue?

The attacker needs local access to reach the autofs responder socket, maintain an open client connection, and repeatedly send valid autofs requests that complete successfully. Memory associated with those successful requests remains allocated until the connection closes.

3

What is the impact of successful exploitation?

Repeated requests over an open connection can exhaust available memory and cause a denial of service. The provided vector indicates no confidentiality or integrity impact.

4

What can be done if patching is not immediately possible?

Disable the SSSD autofs responder service where it is not needed, or restrict local access to its socket. Limiting the ability to maintain connections or submit requests to the responder reduces exposure.

5

How can administrators identify potentially affected systems?

Check whether the SSSD autofs responder is enabled and whether its socket is reachable by local users or processes. Systems running the identified sssd-2.12.0-1.el10 package with that responder enabled should be treated as potentially affected.

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