Fedora Account System
Red Hat Associate
Red Hat Customer
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