Bug 2478663 (CVE-2026-104045) - CVE-2026-104045 sssd: sssd: Denial of Service via race condition in autofs responder
Summary: CVE-2026-104045 sssd: sssd: Denial of Service via race condition in autofs re...
Keywords:
Status: NEW
Alias: CVE-2026-104045
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: 2547126
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-05-18 03:41 UTC by OSIDB Bzimport
Modified: 2026-10-06 20:01 UTC (History)
18 users (show)

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


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-05-18 03:41:43 UTC
AI_ONLY_REPORT
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 `autofs_enum_ctx` 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 `SSS_AUTOFS_GETAUTOMNTENT` and  
`SSS_AUTOFS_SETAUTOMNTENT("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/autofssrv_cmd.c`, primarily `autofs_orphan_maps()`  
and `autofs_setent_done()`.
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: `autofs_setent_send()` creates an enumeration  
context and inserts it into `autofs_ctx->maps`. If  
`SSS_AUTOFS_SETAUTOMNTENT("auto.master")` invalidates maps before the async  
lookup finishes, `autofs_orphan_maps()` removes the hash entries. When the  
outstanding lookup later completes, `autofs_setent_done()` unconditionally  
reparents the now-orphaned `enum_ctx` 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 `sssd_autofs`. This is consistent with a `CWE-401` memory leak triggered  
through race-dependent behavior.
```c
/* src/responder/autofs/autofssrv_cmd.c */
void autofs_orphan_maps(struct autofs_ctx *autofs_ctx)
{
sss_ptr_hash_delete_all(autofs_ctx->maps, false);
}
...
enum_ctx = talloc_zero(mem_ctx, struct autofs_enum_ctx);
...
ret = sss_ptr_hash_add(autofs_ctx->maps, mapname, enum_ctx, struct  
autofs_enum_ctx);
...
if (strcmp(mapname, "auto.master") == 0) {
autofs_orphan_maps(autofs_ctx);
}
...
state->enum_ctx->ready = true;
/* unconditional reparent, even if key was orphaned */
talloc_steal(state->autofs_ctx->maps, state->enum_ctx);
...
sss_ptr_hash_delete(enum_ctx->table, enum_ctx->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 `SSS_AUTOFS_GETAUTOMNTENT` for that map to  
force async enumeration.
3. In a parallel loop, repeatedly issue  
`SSS_AUTOFS_SETAUTOMNTENT("auto.master")` to invalidate maps through  
`autofs_orphan_maps()`.
4. Sustain both loops for several minutes so enumeration completion  
regularly races with invalidation.
5. Observe that `sssd_autofs` 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 `autofs_setent_done()` 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/autofssrv_cmd.c  
b/src/responder/autofs/autofssrv_cmd.c
— a/src/responder/autofs/autofssrv_cmd.c
+++ b/src/responder/autofs/autofssrv_cmd.c
@@ -351,7 +351,13 @@ static void autofs_setent_done(struct tevent_req  
*subreq)
state->enum_ctx->ready = true;
/* Make the enumeration context disappear with maps table. */
   talloc_steal(state->autofs_ctx->maps, state->enum_ctx);
+    if (sss_ptr_hash_has_key(state->autofs_ctx->maps,  
state->enum_ctx->key)) {
+        talloc_steal(state->autofs_ctx->maps, state->enum_ctx);
+    } else {
+        DEBUG(SSSDBG_TRACE_FUNC,
+              "Enumeration context for map [%s] was orphaned during async  
lookup; skipping reparent.\n",
+              state->enum_ctx->key);
+    }


setent_notify_done(&state->enum_ctx->notify_list);
tevent_req_done(req);
```
------
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.