CVE-2026-104032: Sssd: sssd: denial of service via unprivileged autofs cache invalidation
A flaw was found in SSSD. An unprivileged local user can repeatedly request master automount map updates through the autofs responder due to missing authorization checks. This triggers global cache invalidation and forces repeated lookups to backend directory providers, leading to a Denial of Service (DoS) from degraded automount availability and elevated resource consumption.
Other sources
AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: Local DoS in autofs responder via unprivileged auto.master cache invalidation (reproducible): repeated SSSAUTOFSSETAUTOMNTENT("auto.master") requests from a low-privileged local user can invalidate global autofs cache state and force repeated backend refreshes, degrading autofs availability. Requirements to exploit: A low-privileged local account on a host where the autofs responder is enabled and reachable by unprivileged users. The backend-amplification aspect is most visible when automount lookups are active and maps are served from a remote provider such as LDAP, IPA, or AD. Component affected: sssd-2.12.0-1.el10 autofs responder, particularly sssautofscmdsetautomntent() in src/responder/autofs/autofssrvcmd.c and the related cache invalidation path in src/db/sysdbautofs.c and src/responder/common/cachereq/cachereqsearch.c Version affected: sssd-2.12.0-1.el10 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 the host. AC:L - The trigger is a straightforward repeated request for auto.master. PR:L - A low-privileged local user is sufficient; no elevated responder privilege is required. UI:N - No user interaction is needed once the attacker can issue requests. S:U - The impact remains within the same security scope. C:N - No confidentiality impact is established by the available evidence. I:N - No integrity impact is established by the available evidence. A:H - Repeated invalidation can force frequent data-provider lookups and materially degrade autofs lookup availability and backend responsiveness. Impact: Moderate. This is a real availability issue, but it is local rather than remote and no confidentiality, integrity, or privilege-escalation impact is established. Under Red Hat severity guidance, this is better aligned with Moderate than Important because exploitation depends on the autofs responder being deployed and reachable by unprivileged local users, while the demonstrated effect is denial of service rather than broader compromise. Embargo: no Reason: This is a local, configuration-dependent denial of service with operational mitigations available, and no demonstrated confidentiality, integrity, or code-execution impact. Acknowledgement: Aisle Research Vulnerability Details: In src/responder/autofs/autofssrvcmd.c, sssautofscmdsetautomntent() reads the caller-supplied map name and immediately passes it into the master-map invalidation helper: c ret = autofsreadsetautomntentinput(clictx, &cmdctx->mapname); if (ret != EOK) { goto done; } autofsorphanmastermap(autofsctx, cmdctx->mapname); When the requested map is auto.master, the helper invalidates autofs maps across domains: c if (strcmp(mapname, "auto.master") != 0) { return; } DEBUG(SSSDBGTRACEFUNC, "Invalidating master map\n"); / Remove and invalidate all maps. / autofsorphanmaps(autofsctx); DEBUG(SSSDBGTRACEFUNC, "Invalidating autofs maps\n"); for (dom = autofsctx->rctx->domains; dom != NULL; dom = getnextdomain(dom, SSSGNDDESCEND)) { ret = sysdbinvalidateautofsmaps(dom); if (ret != EOK) { DEBUG(SSSDBGMINORFAILURE, "Unable to invalidate maps in " "%s [%d]: %s\n", dom->name, ret, sssstrerror(ret)); } } The invalidation path marks maps expired and invalidates their entries: c ret = sysdbattrsaddtimet(sysattrs, SYSDBCACHEEXPIRE, 1); if (ret != EOK) { goto done; } ... ret = sysdbsetautofsmapattr(domain, name, sysattrs, SYSDBMODREP); if (ret != EOK) { DEBUG(SSSDBGMINORFAILURE, "Could not expire map %s\n", name); continue; } ret = sysdbinvalidateautofsentries(domain, name); if (ret != EOK) { DEBUG(SSSDBGMINORFAILURE, "Could not expire map entries %s\n", name); continue; } Once entries are expired or missing, cache-req falls back to the data provider: c case CACHEOBJECTEXPIRED: case CACHEOBJECTMISSING: CACHEREQDEBUG(SSSDBGTRACEFUNC, state->cr, "Looking up [%s] in data provider\n", state->cr->debugobj); subreq = state->cr->plugin->dpsendfn(state->cr, state->cr, state->cr->data, state->cr->domain, state->result); In the reviewed code path, no autofs-specific alloweduids restriction or equivalent clictx->priv gate is applied before this invalidation step. On deployments where the autofs responder is reachable by unprivileged local users, repeated auto.master requests can keep maps expired and continuously push lookups back to the data provider/backend path. The demonstrated impact is availability degradation through increased local CPU/network use, repeated backend requests, and slower or less reliable autofs lookups. No confidentiality or integrity impact is established from the available evidence. Steps to reproduce: 1. Enable and start the autofs responder with a working external autofs provider such as LDAP, IPA, or AD. 2. From a non-root local account, repeatedly issue SSSAUTOFSSETAUTOMNTENT requests with mapname="auto.master"; libsssautofs client calls are one way to do this. 3. In parallel, trigger normal automount lookups. 4. Observe repeated autofs cache invalidation, renewed data-provider/backend requests, increased local CPU/network activity, and degraded lookup responsiveness. Mitigation: Restrict autofs responder access by service configuration, socket mode, or allowed UIDs so that only the intended trusted client can connect. This reduces exposure before a code fix is deployed. Proposed Fix: Reject non-privileged requests that attempt to invalidate the global master map before calling autofsorphanmastermap(). diff diff --git a/src/responder/autofs/autofssrvcmd.c b/src/responder/autofs/autofssrvcmd.c index XXXXXXX..YYYYYYY 100644 — a/src/responder/autofs/autofssrvcmd.c +++ b/src/responder/autofs/autofssrvcmd.c @@ -465,6 +465,13 @@ sssautofscmdsetautomntent(struct clictx clictx) ret = autofsreadsetautomntentinput(clictx, &cmdctx->mapname); if (ret != EOK) { goto done; } + + / Only privileged callers may invalidate global master-map state. / + if (strcmp(cmdctx->mapname, "auto.master") == 0 && clictx->priv != 1) { + DEBUG(SSSDBGOPFAILURE, + "Access denied for unprivileged auto.master invalidation request\n"); + ret = EACCES; + goto done; + } autofsorphanmastermap(autofsctx, cmdctx->mapname); ------ This report was generated using AI technology. Always review AI-generated content prior to use
— Red Hat
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Restrict access to the SSSD autofs responder through service configuration, socket mode, or allowed UIDs so that only intended trusted clients can connect; ensure unprivileged local users cannot issue auto.master invalidation requests.
Event History
Frequently Asked Questions
Which systems are exposed to this denial-of-service condition?
Hosts running the affected SSSD autofs responder are exposed when it is enabled and reachable by unprivileged local users. Exploitation requires a low-privileged local account on the host.
What conditions make the impact more severe?
The backend load is most apparent when automount lookups are active and maps are provided by a remote directory service, such as LDAP, IPA, or AD. Repeated requests can invalidate global autofs cache state, force backend refreshes, and degrade automount availability.
What does an attacker need to do to trigger the issue?
An unprivileged local user can repeatedly request updates for the master automount map, including SSS_AUTOFS_SETAUTOMNTENT("auto.master"). Missing authorization checks allow these requests to repeatedly invalidate the global autofs cache.