REDHAT-BUG-2478663: Medium severity redhat/sssd vulnerability

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