Bug 2479418 (CVE-2026-104031) - CVE-2026-104031 sssd: SSSD: Denial of Service via memory exhaustion in autofs responder
Summary: CVE-2026-104031 sssd: SSSD: Denial of Service via memory exhaustion in autofs...
Keywords:
Status: NEW
Alias: CVE-2026-104031
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On: 2546211
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-05-18 04:05 UTC by OSIDB Bzimport
Modified: 2026-10-06 03:20 UTC (History)
18 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-05-18 04:05:16 UTC
AI_ONLY_REPORT
package: sssd-2.12.0-1.el10
------
Summary: Local DoS in Autofs responder due to per-request `autofs_cmd_ctx`  
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/autofssrv_cmd.c`  
(`sss_autofs_cmd_setautomntent_done`, `sss_autofs_cmd_getautomntent_done`,  
`sss_autofs_cmd_getautomntbyname_done`) and  
`src/responder/common/responder_cmd.c` (`sss_cmd_done`)
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: `autofs_cmd_ctx` is allocated per request as a child  
of the long-lived client connection context (`cmd_ctx =  
talloc_zero(cli_ctx, struct autofs_cmd_ctx);`). In the async success path,  
the responder writes the reply and then finishes with  
`sss_cmd_done(cmd_ctx->cli_ctx, NULL)`:
```c
sss_autofs_cmd_getautomntent_done(struct tevent_req *req)
{
struct autofs_enum_ctx *enum_ctx;
struct autofs_cmd_ctx *cmd_ctx;
errno_t ret;
cmd_ctx = tevent_req_callback_data(req, struct autofs_cmd_ctx);
ret = autofs_setent_recv(cmd_ctx, req, &enum_ctx);
talloc_zfree(req);
if (ret != EOK) {
autofs_cmd_done(cmd_ctx, ret);
return;
}
ret = autofs_write_getautomntent_output(cmd_ctx->cli_ctx, enum_ctx,
cmd_ctx->cursor,
cmd_ctx->max_entries);
if (ret != EOK) {
DEBUG(SSSDBG_CRIT_FAILURE, "Unable to create reply packet "
"[%d]: %s\n", ret, sss_strerror(ret));
autofs_cmd_done(cmd_ctx, ret);
return;
}
sss_cmd_done(cmd_ctx->cli_ctx, NULL);
}
```
`sss_cmd_done()` only frees the explicit `freectx` argument:
```c
void sss_cmd_done(struct cli_ctx *cctx, void *freectx)
{
/* now that the packet is in place, unlock queue
making the event writable */
     TEVENT_FD_WRITEABLE(cctx->cfde);


/* free all request related data through the talloc hierarchy */
talloc_free(freectx);
}
```
The same success-path pattern is present in  
`sss_autofs_cmd_setautomntent_done` and  
`sss_autofs_cmd_getautomntbyname_done`. By contrast, handled error paths  
use `autofs_cmd_done(cmd_ctx, ret)`, which frees `cmd_ctx`, so the retained  
lifetime appears limited to successful asynchronous completions. In the  
`GETAUTOMNTENT` path, `autofs_setent_recv(cmd_ctx, req, &enum_ctx)`  
additionally does `*_enum_ctx = talloc_reference(mem_ctx,  
state->enum_ctx);`; because `cmd_ctx` is used as `mem_ctx`, 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 `cmd_ctx` instead of `NULL` to `sss_cmd_done()` in the  
three async success callbacks so the per-request context is released after  
successful completion.
```diff
diff --git a/src/responder/autofs/autofssrv_cmd.c  
b/src/responder/autofs/autofssrv_cmd.c
— a/src/responder/autofs/autofssrv_cmd.c
+++ b/src/responder/autofs/autofssrv_cmd.c
@@ -517,7 +517,7 @@ sss_autofs_cmd_setautomntent_done(struct tevent_req  
*req)
   sss_cmd_done(cmd_ctx->cli_ctx, NULL);
+    sss_cmd_done(cmd_ctx->cli_ctx, cmd_ctx);
@@ -727,7 +727,7 @@ sss_autofs_cmd_getautomntent_done(struct tevent_req  
*req)

   sss_cmd_done(cmd_ctx->cli_ctx, NULL);
+    sss_cmd_done(cmd_ctx->cli_ctx, cmd_ctx);
@@ -927,7 +927,7 @@ sss_autofs_cmd_getautomntbyname_done(struct tevent_req  
*req)

   sss_cmd_done(cmd_ctx->cli_ctx, NULL);
+    sss_cmd_done(cmd_ctx->cli_ctx, cmd_ctx);
```


------
This report was generated using AI technology. Always review AI-generated  
content prior to use


Note You need to log in before you can comment on or make changes to this bug.