Bug 2479381 (CVE-2026-104032) - CVE-2026-104032 sssd: sssd: Denial of Service via unprivileged autofs cache invalidation
Summary: CVE-2026-104032 sssd: sssd: Denial of Service via unprivileged autofs cache i...
Keywords:
Status: NEW
Alias: CVE-2026-104032
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: 2546212
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-05-18 04:04 UTC by OSIDB Bzimport
Modified: 2026-10-05 23:25 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:04:07 UTC
AI_ONLY_REPORT
package: sssd-2.12.0-1.el10
------
Summary: Local DoS in autofs responder via unprivileged `auto.master` cache  
invalidation (reproducible): repeated  
`SSS_AUTOFS_SETAUTOMNTENT("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  
`sss_autofs_cmd_setautomntent()` in `src/responder/autofs/autofssrv_cmd.c`  
and the related cache invalidation path in `src/db/sysdb_autofs.c` and  
`src/responder/common/cache_req/cache_req_search.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/autofssrv_cmd.c`,  
`sss_autofs_cmd_setautomntent()` reads the caller-supplied map name and  
immediately passes it into the master-map invalidation helper:
```c
ret = autofs_read_setautomntent_input(cli_ctx, &cmd_ctx->mapname);
if (ret != EOK) {
goto done;
}
autofs_orphan_master_map(autofs_ctx, cmd_ctx->mapname);
```
When the requested map is `auto.master`, the helper invalidates autofs maps  
across domains:
```c
if (strcmp(mapname, "auto.master") != 0) {
return;
}
DEBUG(SSSDBG_TRACE_FUNC, "Invalidating master map\n");
/* Remove and invalidate all maps. */
autofs_orphan_maps(autofs_ctx);
DEBUG(SSSDBG_TRACE_FUNC, "Invalidating autofs maps\n");
for (dom = autofs_ctx->rctx->domains;
dom != NULL;
dom = get_next_domain(dom, SSS_GND_DESCEND)) {
ret = sysdb_invalidate_autofs_maps(dom);
if (ret != EOK) {
DEBUG(SSSDBG_MINOR_FAILURE, "Unable to invalidate maps in "
"%s [%d]: %s\n", dom->name, ret, sss_strerror(ret));
}
}
```
The invalidation path marks maps expired and invalidates their entries:
```c
ret = sysdb_attrs_add_time_t(sys_attrs, SYSDB_CACHE_EXPIRE, 1);
if (ret != EOK) {
goto done;
}
...
ret = sysdb_set_autofsmap_attr(domain, name,
sys_attrs, SYSDB_MOD_REP);
if (ret != EOK) {
DEBUG(SSSDBG_MINOR_FAILURE, "Could not expire map %s\n", name);
continue;
}
ret =  sysdb_invalidate_autofs_entries(domain, name);
if (ret != EOK) {
DEBUG(SSSDBG_MINOR_FAILURE, "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 CACHE_OBJECT_EXPIRED:
case CACHE_OBJECT_MISSING:
CACHE_REQ_DEBUG(SSSDBG_TRACE_FUNC, state->cr,
"Looking up [%s] in data provider\n",
state->cr->debugobj);
subreq = state->cr->plugin->dp_send_fn(state->cr, state->cr,
state->cr->data,
state->cr->domain,
state->result);
```
In the reviewed code path, no autofs-specific `allowed_uids` restriction or  
equivalent `cli_ctx->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  
`SSS_AUTOFS_SETAUTOMNTENT` requests with `mapname="auto.master"`;  
`libsss_autofs` 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 `autofs_orphan_master_map()`.
```diff
diff --git a/src/responder/autofs/autofssrv_cmd.c  
b/src/responder/autofs/autofssrv_cmd.c
index XXXXXXX..YYYYYYY 100644
— a/src/responder/autofs/autofssrv_cmd.c
+++ b/src/responder/autofs/autofssrv_cmd.c
@@ -465,6 +465,13 @@ sss_autofs_cmd_setautomntent(struct cli_ctx *cli_ctx)
ret = autofs_read_setautomntent_input(cli_ctx, &cmd_ctx->mapname);
if (ret != EOK) {
goto done;
}
+
+    /* Only privileged callers may invalidate global master-map state. */
+    if (strcmp(cmd_ctx->mapname, "auto.master") == 0 && cli_ctx->priv !=  
1) {
+        DEBUG(SSSDBG_OP_FAILURE,
+              "Access denied for unprivileged auto.master invalidation  
request\n");
+        ret = EACCES;
+        goto done;
+    }
autofs_orphan_master_map(autofs_ctx, cmd_ctx->mapname);
```
------
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.