A flaw was found in SSSD. When configured to use Microsoft Entra ID, search inputs are not properly sanitized before being incorporated into directory query filters. A local user can exploit this vulnerability by submitting a crafted lookup request, manipulating the query logic to cause unauthorized information disclosure from the directory.

A flaw was found in SSSD. In trust-enabled identity management environments, SSSD evaluates Host-Based Access Control (HBAC) rules by stripping domain qualifiers and comparing only short usernames. An authenticated user in a trusted domain who shares the same username as an authorized local account can bypass access policies and gain unauthorized access to protected services or hosts.

A flaw was found in SSSD (System Security Services Daemon). When Identity Provider (IdP) authentication is enabled, pre-authentication requests retain state in memory without being cleared or timed out. A local attacker can repeatedly initiate authentication flows without completing them, causing unbounded memory consumption. This memory exhaustion can lead to a Denial of Service (DoS) by degrading or terminating SSSD authentication services.

A flaw was found in sssd. A local attacker can trigger a Denial of Service (DoS) by sending a specially crafted Pluggable Authentication Module (PAM) request when passkey authentication is enabled. Due to a missing state validation check in passkey Kerberos handling, the PAM responder dereferences an uninitialized pointer and crashes. This failure disrupts authentication services on the host.

A flaw was found in SSSD. A local user can cause a denial of service (DoS) by disrupting system authentication services. When handling Generic Security Services Application Programming Interface (GSSAPI) authentication in the Pluggable Authentication Module (PAM) responder, cached connection state is freed upon completion without clearing the reference pointer. An attacker can exploit this by sending an additional request over the same connection, causing the service to access invalid memory and unexpectedly terminate.

A flaw was found in SSSD. A local attacker can exploit this vulnerability by sending a specially crafted request to the autofs responder UNIX socket. Due to improper buffer offset calculation during request parsing, the service performs an out-of-bounds memory read. This flaw can cause the autofs responder process to crash, resulting in a denial of service (DoS).

A flaw was found in sssd. A local attacker can cause a Denial of Service (DoS) by sending a crafted Pluggable Authentication Module (PAM) request containing a zero-length authentication token to the responder socket. Due to missing input validation, the service attempts to read beyond buffer boundaries when processing the token, causing the PAM responder to crash.

A flaw was found in sssd. A remote attacker can cause a denial of service (DoS) by submitting a certificate that lacks an expected Security Identifier (SID) extension. In deployments configured with SID-based certificate mapping rules, the service fails to verify the presence of the extension before processing it, causing the process to crash during authentication or lookup operations.

A flaw was found in SSSD. When configured to enforce account expiration using LDAP (Lightweight Directory Access Protocol) shadow attributes, SSSD fails to treat an expiration value of zero as an expired account. A user with valid credentials for an expired account can exploit this flaw to bypass access controls and authenticate to the system. This allows unauthorized access to persist after the account was intended to be deactivated.

A flaw was found in sssd-kcm. A local user or process able to connect to the sssd-kcm UNIX socket can exploit this vulnerability. By sending a large request length header and then stalling the connection, an attacker can cause the system to preallocate significant memory. This leads to memory exhaustion within the sssd-kcm responder, resulting in a Denial of Service (DoS) for affected deployments.

A flaw was found in SSSD. A local user can trigger a Denial of Service (DoS) by exploiting a race condition in the autofs responder between asynchronous enumeration completion and map invalidation. By repeatedly sending concurrent map enumeration and invalidation requests, an attacker can cause memory to leak, leading to excessive memory consumption that can disrupt or crash the autofs service.

AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: Local DoS in responder accept() path via EMFILE/ENFILE retry spin: a local user who can reach an affected responder UNIX socket can force accept() failures under file descriptor exhaustion and trigger a busy retry loop that stalls responder service. Requirements to exploit: Local access to a responder UNIX socket serviced by acceptfdhandler(), plus the ability to create and hold enough concurrent connections to push the responder into EMFILE or ENFILE while keeping the listen queue non-empty. Practical reachability depends on an affected responder being enabled and locally reachable. Component affected: sssd-2.12.0-1.el10, src/responder/common/respondercommon.c, acceptfdhandler() Version affected: sssd-2.12.0-1.el10; practical exploitation depends on an enabled responder using this common local socket accept path 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:H/PR:N/UI:N/S:U/C:N/I:N/A:H - 5.5 (MEDIUM) AV:L - exploitation requires local access to a reachable responder UNIX socket. AC:H - the attacker must sustain responder-side file descriptor exhaustion and keep the listen queue populated so the handler repeatedly wakes without making progress. PR:N - based on the available evidence, no prior privileges beyond local access are required to trigger the condition. UI:N - no user interaction is needed. S:U - the impact remains within the affected responder service boundary. C:N - no confidentiality impact is established by the available evidence. I:N - no integrity impact is established by the available evidence. A:H - the responder can enter a high-CPU retry loop and stop servicing legitimate requests. Impact: Moderate. The issue can substantially degrade availability of an enabled responder, but the established impact is local and availability-only, and exploitation depends on local socket reachability plus sustained file descriptor pressure. Under Red Hat's severity guidance, that fits Moderate more closely than Important or Critical. Embargo: no Reason: The available evidence supports a local denial of service rather than system compromise, confidentiality loss, or integrity loss, and the issue does not present a credible wormable or remotely exploitable scenario. Acknowledgement: Aisle Research Vulnerability Details: acceptfdhandler() accepts incoming connections for responder sockets. When accept() fails, the handler logs the error, frees the client context, and returns immediately: c cctx->cfd = accept(rctx->lfd, (struct sockaddr )&cctx->addr, &len); if (cctx->cfd == -1) { DEBUG(SSSDBGCRITFAILURE, "Accept failed [%s]\n", strerror(errno)); tallocfree(cctx); return; } The listener remains persistently registered as readable: c rctx->lfde = teventaddfd(rctx->ev, rctx, rctx->lfd, TEVENTFDREAD, acceptfdhandler, acceptctx); No EMFILE/ENFILE-specific backoff, temporary TEVENTFDNOTREADABLE, or reserved-fd drain logic is present in this path. If the responder runs out of file descriptors while additional local connections remain queued, the event loop can repeatedly re-enter acceptfdhandler() with no forward progress. Based on the available evidence, the result is sustained CPU consumption and stalled legitimate requests, not demonstrated confidentiality or integrity impact. Steps to reproduce: 1. Run sssd-2.12.0-1.el10 with a responder using this common UNIX socket accept path, such as an NSS or PAM responder. 2. Set a low responder file descriptor limit for quick reproduction, for example fdlimit = 256, and restart the responder. 3. As an unprivileged local user, open and hold many concurrent connections to the responder socket until the responder exhausts its available file descriptors. 4. Continue making connection attempts so the listen queue remains non-empty. 5. Observe repeated Accept failed [Too many open files] log messages, sustained responder CPU use, and stalled or timed-out legitimate requests. 6. Reduce the connection pressure or restart the responder to recover service. Mitigation: Where operationally possible, restrict access to affected responder UNIX sockets and avoid unnecessarily low fdlimit settings. Monitoring for repeated Accept failed [Too many open files] log entries can help detect the condition early. These measures reduce exposure but do not address the missing backoff in the accept() failure path; if the condition is triggered, reducing connection pressure or restarting the affected responder restores service. Proposed Fix: A minimal fix is to treat EMFILE and ENFILE as a special case, temporarily clear readability on the listening fd, and re-enable it on a short timer so the event loop does not spin indefinitely. diff diff --git a/src/responder/common/respondercommon.c b/src/responder/common/respondercommon.c index 0000000..0000000 100644 — a/src/responder/common/respondercommon.c +++ b/src/responder/common/respondercommon.c @@ struct acceptfdctx { struct respctx rctx; connectionsetupt connectionsetup; + struct teventtimer resumeaccepttimer; }; + +static void acceptresumetimer(struct teventcontext ev, + struct teventtimer te, + struct timeval tv, + void pvt) +{ + struct acceptfdctx acceptctx = tallocgettype(pvt, struct acceptfdctx); + acceptctx->resumeaccepttimer = NULL; + TEVENTFDREADABLE(acceptctx->rctx->lfde); +} @@ cctx->cfd = accept(rctx->lfd, (struct sockaddr )&cctx->addr, &len); if (cctx->cfd == -1) { DEBUG(SSSDBGCRITFAILURE, "Accept failed [%s]\n", strerror(errno)); + int err = errno; + DEBUG(SSSDBGCRITFAILURE, "Accept failed [%s]\n", strerror(err)); + + if ((err == EMFILE || err == ENFILE) && + acceptctx->resumeaccepttimer == NULL) { + struct timeval tv = teventtimevalcurrentofs(0, 200000); / 200ms / + TEVENTFDNOTREADABLE(fde); + acceptctx->resumeaccepttimer = teventaddtimer(ev, acceptctx, tv, + acceptresumetimer, + acceptctx); + } tallocfree(cctx); return; }

------ This report was generated using AI technology. Always review AI-generated content prior to use

AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: Unbounded openrequesttable growth in IdP PREAUTH can cause local DoS (memory exhaustion): repeated successful PREAUTH flows can retain stale per-request state in a process-lifetime hash table without a size bound, timeout, or proactive cleanup, allowing local memory exhaustion when AUTHENTICATE is never completed. Requirements to exploit: A local attacker must be able to reach a PAM authentication surface handled by sssd-2.12.0-1.el10 with IdP authentication enabled, repeatedly drive PREAUTH to a successful device-authorization reply, and stop before completing the matching AUTHENTICATE step for each returned usercode. Component affected: sssd-2.12.0-1.el10, IdP authentication backend in src/providers/idp/idpautheval.c (evaldeviceauthbuf()), src/providers/idp/idpauth.c (getstoredrequestdata()), and src/providers/idp/idpinit.c (sssmidpauthinit()). Version affected: sssd-2.12.0-1.el10 when IdP authentication is enabled and the PREAUTH device-authorization flow is reachable. 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 - The attack requires local access to a PAM authentication surface on the affected host. AC:L - Once IdP authentication is enabled, repeatedly driving PREAUTH and withholding AUTHENTICATE is straightforward. PR:N - No prior privileges are required before attempting authentication. UI:N - No separate victim interaction is required. S:U - The impact remains within the same security scope. C:N - No confidentiality impact was established. I:N - No integrity impact was established. A:H - Persistent growth of stored request state can exhaust backend memory and disrupt authentication services. Impact: Moderate. This is a real availability issue on affected deployments, but it is local and configuration-dependent rather than a remote or default-path compromise. Based on Red Hat severity guidance, that fits Moderate better than Important or Critical. Embargo: no Reason: The demonstrated impact is local and availability-only, depends on IdP-enabled deployments, and has straightforward operational mitigation while a code fix is prepared. Acknowledgement: Aisle Research Vulnerability Details: In the IdP PREAUTH path, successful device-authorization replies allocate and store per-request state in openrequesttable with no size limit, timeout, or eviction in the shown path: c / src/providers/idp/idpautheval.c / openreq = talloczero(idpauthctx, struct idpopenreqdata); openreq->devicecodedata = tallocstrdup(openreq, (char ) buf); ret = sssptrhashadd(idpauthctx->openrequesttable, userdata->usercode, openreq, struct idpopenreqdata); The corresponding cleanup occurs only later in getstoredrequestdata() during SSSPAMAUTHENTICATE, where the entry is looked up by usercode and then freed. The table itself is created under authctx in sssmidpauthinit(), so it persists for backend lifetime. As a result, PREAUTH requests that successfully reach evaldeviceauthbuf() but never complete AUTHENTICATE can leave stale entries behind. Repeated successful PREAUTH flows that produce fresh usercode values can therefore grow the table over time, increasing backend RSS and potentially degrading or terminating the affected SSSD backend under memory pressure. The available evidence supports availability impact only; no confidentiality, integrity, or privilege-escalation impact was established. Steps to reproduce: 1. Configure a test domain with IdP auth enabled (idp options set; IdP provider active). 2. Start SSSD and identify the IdP backend PID. 3. Trigger many PREAUTH attempts that reach evaldeviceauthbuf() success, but never submit the matching OAuth2 usercode in AUTHENTICATE. 4. Observe growth during the run with while true; do ps -o pid,rss,cmd -p <pid>; sleep 2; done. Optional debug logs should show repeated successful PREAUTH handling with no matching AUTHENTICATE cleanup path. 5. Confirm memory is not reclaimed over time unless matching AUTHENTICATE happens. Prolonged runs can degrade or terminate the backend under memory pressure. Mitigation: Deployments that do not enable IdP authentication are not exposed to this path. Until a fix is available, disable the affected IdP authentication configuration where possible, restrict who can reach PAM services that exercise this flow, and restart the affected SSSD backend or service if memory growth is observed to reclaim accumulated entries. Proposed Fix: A minimal fix is to record request age, reject overly old stored requests, and bound the number of pending requests. diff diff --git a/src/providers/idp/idpprivate.h b/src/providers/idp/idpprivate.h index 3a2b0b7..e19f2d2 100644 — a/src/providers/idp/idpprivate.h +++ b/src/providers/idp/idpprivate.h @@ -51,6 +51,7 @@ requests. / struct idpopenreqdata { + timet createdat; char devicecodedata; };

diff --git a/src/providers/idp/idpautheval.c b/src/providers/idp/idpautheval.c index 7f6a9e2..3f0d8bc 100644 — a/src/providers/idp/idpautheval.c +++ b/src/providers/idp/idpautheval.c @@ -22,6 +22,7 @@ #include <errno.h> +#include <time.h> #include <jansson.h> @@ -41,6 +42,8 @@ errnot evaldeviceauthbuf(struct idpauthctx idpauthctx, struct sssidpoauth2 userdata = NULL; int ret; struct idpopenreqdata openreq = NULL; + const sizet maxopenrequests = 1024; + timet now; @@ -76,6 +79,13 @@ errnot evaldeviceauthbuf(struct idpauthctx idpauthctx, goto done; } + if (hashcount(idpauthctx->openrequesttable) >= maxopenrequests) { + DEBUG(SSSDBGOPFAILURE, "Too many pending IdP auth requests.\n"); + ret = ENOSPC; + goto done; + } + + now = time(NULL); openreq = talloczero(idpauthctx, struct idpopenreqdata); if (openreq == NULL) { @@ -83,6 +93,7 @@ errnot evaldeviceauthbuf(struct idpauthctx idpauthctx, ret = ENOMEM; goto done; } + openreq->createdat = now; diff --git a/src/providers/idp/idpauth.c b/src/providers/idp/idpauth.c index 28baf1c..2d1a644 100644 — a/src/providers/idp/idpauth.c +++ b/src/providers/idp/idpauth.c @@ -23,6 +23,7 @@ #include <security/pammodules.h> +#include <time.h> @@ -152,6 +153,7 @@ static const char getstoredrequestdata(TALLOCCTX memctx, const char usercode; sizet usercodelen; + const timet maxage = 300; @@ -176,6 +178,12 @@ static const char getstoredrequestdata(TALLOCCTX memctx, DEBUG(SSSDBGOPFAILURE, "Missing device code data.\n"); goto done; } + if (time(NULL) - openreq->createdat > maxage) { + DEBUG(SSSDBGOPFAILURE, "Stored device auth request expired.\n"); + senddata = NULL; + goto done; + } + This is intentionally minimal; a stronger fix would also proactively prune expired entries from the full table. ------ This report was generated using AI technology. Always review AI-generated content prior to use

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

AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: OData Filter Injection in Entra ID Lookup (oidcchildid.c) Enables Overbroad Directory Queries: crafted lookup values containing single quotes can escape intended OData string literals and broaden Entra directory queries issued by the affected lookup path. Requirements to exploit: A low-privileged local actor must be able to trigger name-based lookups on a system that builds and uses the Entra ID provider path (idptype=entraid) with valid directory client credentials and scopes. No separate user interaction is required. Component affected: sssd-2.12.0-1.el10, src/oidcchild/oidcchildid.c, entraidlookup(). Version affected: sssd-2.12.0-1.el10 when the Entra ID provider path is built and deployed with idptype=entraid. 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:L/I:L/A:L - 5.3 (MEDIUM) AV:L - The issue is reached through a local lookup path rather than direct remote network exposure. AC:L - A crafted lookup value containing a single quote is sufficient to alter the generated OData predicate. PR:L - The attacker needs low privileges sufficient to trigger account or group lookups on the affected system. UI:N - No additional user interaction is required once the lookup is issued. S:U - The impact stays within the same SSSD/IdP lookup security scope. C:L - Successful exploitation can return broader directory metadata than intended, but the exposed data depends on granted directory permissions and deployment details. I:L - The lookup predicate can be changed from the intended exact or prefix match to attacker-influenced logic. A:L - Overbroad responses can increase parsing, processing, and cache activity, but the available evidence does not establish reliable high-impact exhaustion in all environments. Impact: Moderate. This issue does not match Red Hat's Important or Critical guidance because it is not an unauthenticated remote compromise path and depends on a specific Entra ID configuration. In affected deployments, however, a low-privileged local actor can change query logic, potentially obtain broader directory results than intended, and drive additional processing or cache pressure. That supports a configuration-dependent compromise of confidentiality, integrity, and availability consistent with a Moderate rating. Embargo: no Reason: The issue is locally triggered, configuration-dependent, and the demonstrated impact is overbroad queries plus extra processing rather than remote system compromise. A straightforward code fix exists, so normal coordinated disclosure is appropriate. Acknowledgement: Aisle Research Vulnerability Details: In sssd-2.12.0-1.el10, the Entra ID lookup path builds OData $filter expressions by inserting user-controlled input into single-quoted literals without escaping embedded single quotes: c filter = tallocasprintf(restctx, "startsWith(userPrincipalName,'%s@')", input); filter = tallocasprintf(restctx, "mail eq '%s' or userPrincipalName eq '%s'", input, input); filter = tallocasprintf(restctx, "displayName eq '%s'", input); filter = tallocasprintf(restctx, "displayName eq '%s' or displayName eq '%s'", input, shortname); Only URL encoding is applied afterward: c filterenc = urlencodestring(restctx, filter); The observed call path shows that the lookup value is forwarded into --name=%s, sssparseinternalfqname() does not remove quote characters, and returned arrays are later iterated and stored in cache. Based on that behavior, a crafted lookup value containing ' can terminate the intended OData string literal and append additional predicate logic after the request is decoded by the server. The available evidence supports overbroad directory queries and additional backend processing in affected Entra ID deployments. It does not establish arbitrary code execution, and the maximum disclosure or availability impact will vary with configuration, granted directory permissions, and server-side response limits such as paging. Steps to reproduce: 1. Configure the affected package to use the IdP provider with idptype=entraid and valid directory client credentials/scopes. 2. Trigger a name-based lookup with a crafted value containing a single quote, for example a') or startsWith(userPrincipalName,'') or ('1' eq '1. 3. Enable SSSD debug logging or --libcurl-debug and inspect the outgoing request to the directory /users?$filter= or /groups?$filter= endpoint. 4. Confirm that, after URL decoding, the generated $filter contains injected or ... logic instead of a single intended literal comparison or prefix test. 5. Compare the response and downstream processing against a benign lookup and observe that the injected request can return a broader result set that is then iterated and stored by the IdP evaluation path. Mitigation: Until a package fix is available, avoid enabling the Entra ID provider path where it is not required. Where Entra ID integration is required, restrict who can trigger name-based lookups with untrusted input and monitor for unexpectedly broad directory $filter requests. These measures reduce exposure but do not eliminate the underlying flaw. Proposed Fix: Escape single quotes in OData string literals before interpolation so that lookup values cannot break out of the intended literal. The following minimal patch addresses the affected construction sites: diff diff --git a/src/oidcchild/oidcchildid.c b/src/oidcchild/oidcchildid.c — a/src/oidcchild/oidcchildid.c +++ b/src/oidcchild/oidcchildid.c @@ +static char odataescapesinglequotes(TALLOCCTX memctx, const char in) +{ + sizet i; + char out = NULL; + + if (in == NULL) return NULL; + out = tallocstrdup(memctx, ""); + if (out == NULL) return NULL; + + for (i = 0; in[i] != '\0'; i++) { + out = (in[i] == '\'') ? tallocasprintfappend(out, "''") + : tallocasprintfappend(out, "%c", in[i]); + if (out == NULL) return NULL; + } + return out; +} @@ char filter; + char filter; + char inputesc = NULL; + char shortnameesc = NULL; @@ + inputesc = odataescapesinglequotes(restctx, input); + if (inputesc == NULL) { ret = ENOMEM; goto done; } @@

filter = tallocasprintf(restctx, "startsWith(userPrincipalName,'%s@')", input); + filter = tallocasprintf(restctx, "startsWith(userPrincipalName,'%s@')", inputesc); @@

input, input); + inputesc, inputesc); @@

filter = tallocasprintf(restctx, "displayName eq '%s'", input); + filter = tallocasprintf(restctx, "displayName eq '%s'", inputesc); @@

filter = tallocasprintf(restctx, "displayName eq '%s'", input); + filter = tallocasprintf(restctx, "displayName eq '%s'", inputesc); } else { + shortnameesc = odataescapesinglequotes(restctx, shortname); + if (shortnameesc == NULL) { ret = ENOMEM; goto done; } filter = tallocasprintf(restctx, "displayName eq '%s' or displayName eq '%s'",

input, shortname); + inputesc, shortnameesc); }

------ This report was generated using AI technology. Always review AI-generated content prior to use

A flaw was found in SSSD. A local attacker with access to the Name Service Switch (NSS) responder UNIX socket can trigger an integer underflow by sending a specially crafted request with an undersized packet header. This issue causes an out-of-bounds memory read during packet parsing, crashing the responder process and resulting in a Denial of Service (DoS).

A flaw was found in sssd. This vulnerability allows a local user to cause a Denial of Service (DoS) by submitting a specially crafted passkey authentication token that lacks null terminators. The authentication service reads past the end of the provided memory buffer, causing the process to crash and disrupting authentication services.

A flaw was found in SSSD. In configurations where the autofs responder service is enabled, memory allocated during successful request processing is not released until the client connection terminates. A local attacker can exploit this vulnerability by maintaining an open connection and repeatedly submitting valid requests, leading to memory exhaustion and a Denial of Service (DoS).

A flaw was found in SSSD. A local attacker can exploit this issue by sending a specially crafted request with an invalid packet length to the autofs responder UNIX socket. This causes an integer underflow and an out-of-bounds memory read, which can crash the responder process and result in a denial of service (DoS).

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.

A flaw was found in SSSD's NFS idmap plugin. When retrieving cached user or group names, the plugin detects if an entry exceeds the destination buffer size but fails to abort before copying data. A local attacker can trigger this vulnerability by requesting identity lookups that resolve to oversized cached entries, resulting in an out-of-bounds write. This flaw primarily leads to a Denial of Service (DoS) by crashing the identity mapping service, and may also corrupt adjacent process memory.

A flaw was found in SSSD. An unprivileged local user can repeatedly request lookups for nonexistent entries through the Name Service Switch (NSS) responder. Because the negative cache does not limit the total number of stored entries and only removes expired records when an existing key is rechecked, the cache can grow without bound. This behavior can lead to memory exhaustion, resulting in a Denial of Service (DoS) as the responder becomes unresponsive or terminates.

A flaw was found in SSSD. When configured with the Entra ID identity provider, input lookup names containing single quotes are not properly escaped before being included in Microsoft Graph Open Data Protocol (OData) queries. A low-privileged local user can exploit this flaw by submitting a crafted search request, altering query filters to broaden user or group searches. This can lead to information disclosure by retrieving unintended directory objects, as well as a Denial of Service (DoS) through excessive processing and cache population.

AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: Local DoS in Autofs responder due to per-request autofscmdctx lifetime bug (and pinned enum references): successful autofs responder requests can retain per-request state until connection close, allowing local memory exhaustion when the autofs responder/socket is enabled and reachable. Requirements to exploit: A local actor must be able to reach the autofs responder/socket in an affected deployment, keep a client connection open, and send a large number of valid autofs requests that complete successfully. Component affected: sssd-2.12.0-1.el10 Autofs responder, primarily src/responder/autofs/autofssrvcmd.c (sssautofscmdsetautomntentdone, sssautofscmdgetautomntentdone, sssautofscmdgetautomntbynamedone) and src/responder/common/respondercmd.c (ssscmddone) Version affected: sssd-2.12.0-1.el10, when the autofs responder/socket is enabled and reachable by a local user 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 a reachable autofs responder/socket. AC:L - The issue can be triggered by repeatedly sending valid successful requests over one connection. PR:L - The attacker must be able to use the local autofs responder in an affected deployment; the available evidence does not establish anonymous reachability for all configurations. UI:N - No user interaction is required once the attacker can reach the responder. S:U - The impact remains within the SSSD responder's security scope. C:N - No confidentiality impact is shown by the available evidence. I:N - No integrity impact is shown by the available evidence. A:H - Repeated retained request contexts can exhaust responder memory and disrupt service. Impact: Moderate. This is an availability issue with a credible memory-exhaustion outcome, but the demonstrated attack is local and depends on the autofs responder/socket being enabled and reachable. Under Red Hat's severity guidance, that is better classified as Moderate than Important because the report does not establish remote reachability, privilege escalation, or broader system compromise. Embargo: no Reason: The demonstrated impact is local, availability-only, and configuration-dependent, and practical mitigation exists by disabling or restricting access to the autofs responder until a fix is shipped. Acknowledgement: Aisle Research Vulnerability Details: autofscmdctx is allocated per request as a child of the long-lived client connection context (cmdctx = talloczero(clictx, struct autofscmdctx);). In the async success path, the responder writes the reply and then finishes with ssscmddone(cmdctx->clictx, NULL): c sssautofscmdgetautomntentdone(struct teventreq req) { struct autofsenumctx enumctx; struct autofscmdctx cmdctx; errnot ret; cmdctx = teventreqcallbackdata(req, struct autofscmdctx); ret = autofssetentrecv(cmdctx, req, &enumctx); talloczfree(req); if (ret != EOK) { autofscmddone(cmdctx, ret); return; } ret = autofswritegetautomntentoutput(cmdctx->clictx, enumctx, cmdctx->cursor, cmdctx->maxentries); if (ret != EOK) { DEBUG(SSSDBGCRITFAILURE, "Unable to create reply packet " "[%d]: %s\n", ret, sssstrerror(ret)); autofscmddone(cmdctx, ret); return; } ssscmddone(cmdctx->clictx, NULL); } ssscmddone() only frees the explicit freectx argument: c void ssscmddone(struct clictx cctx, void freectx) { / now that the packet is in place, unlock queue making the event writable / TEVENTFDWRITEABLE(cctx->cfde);

/ free all request related data through the talloc hierarchy / tallocfree(freectx); } The same success-path pattern is present in sssautofscmdsetautomntentdone and sssautofscmdgetautomntbynamedone. By contrast, handled error paths use autofscmddone(cmdctx, ret), which frees cmdctx, so the retained lifetime appears limited to successful asynchronous completions. In the GETAUTOMNTENT path, autofssetentrecv(cmdctx, req, &enumctx) additionally does enumctx = tallocreference(memctx, state->enumctx);; because cmdctx is used as memctx, leaked request contexts can also retain that extra reference. Repeating successful requests over one long-lived connection can therefore grow responder memory until the connection is closed or the process is restarted. Steps to reproduce: 1. Run SSSD with the autofs responder enabled and ensure the autofs responder/socket is reachable in the target deployment. 2. Open one persistent client connection to the autofs responder. 3. Over that same connection, send a high volume of valid successful SETAUTOMNTENT, GETAUTOMNTENT, or GETAUTOMNTBYNAME requests. 4. Observe responder RSS or heap usage while the connection remains open. 5. Confirm that memory usage grows with request count and does not return to baseline until the connection is closed or the process is restarted. 6. Optionally apply the three-line patch below and repeat the same request pattern; the per-request accumulation should stop. Mitigation: If the autofs responder is not required, disable it. Otherwise, restrict access to the autofs responder/socket to trusted local clients only until a fixed package is available. Closing long-lived client connections or restarting the responder reclaims retained objects, but that is operational containment rather than a complete fix. Proposed Fix: Pass cmdctx instead of NULL to ssscmddone() in the three async success callbacks so the per-request context is released after successful completion. 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 @@ -517,7 +517,7 @@ sssautofscmdsetautomntentdone(struct teventreq req) ssscmddone(cmdctx->clictx, NULL); + ssscmddone(cmdctx->clictx, cmdctx); @@ -727,7 +727,7 @@ sssautofscmdgetautomntentdone(struct teventreq req)

ssscmddone(cmdctx->clictx, NULL); + ssscmddone(cmdctx->clictx, cmdctx); @@ -927,7 +927,7 @@ sssautofscmdgetautomntbynamedone(struct teventreq req)

ssscmddone(cmdctx->clictx, NULL); + ssscmddone(cmdctx->clictx, cmdctx);

------ This report was generated using AI technology. Always review AI-generated content prior to use

AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: Reachable NULL Pointer Dereference in passkeykerberos (SSSAUTHTOKTYPEPASSKEYKRB) causing Local DoS: crafted local PAM authentication requests can reach passkeykerberos() before passkey pre-auth state is initialized and crash sssdpam. Requirements to exploit: Local access to the PAM responder socket and the ability to send a crafted SSSPAMAUTHENTICATE request with authtok type SSSAUTHTOKTYPEPASSKEYKRB, a non-NULL passkey prompt and key, and no prior successful SSSPAMPREAUTH that would initialize pktabledata. The affected path is present only when the package is built with BUILDPASSKEY and pampasskeyauth is enabled; deployments that restrict PAM responder access to trusted users reduce reachability. Component affected: sssd-2.12.0-1.el10, PAM responder passkey handling in src/responder/pam/pamsrvpasskey.c (passkeykerberos()), with reachability from src/responder/pam/pamsrvcmd.c and state initialization in savepasskeydata(). Version affected: sssd-2.12.0-1.el10, when built with passkey support (BUILDPASSKEY) and with pampasskeyauth = true 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 the PAM responder socket. AC:L - the attacker only needs to send a crafted request that selects SSSAUTHTOKTYPEPASSKEYKRB without first establishing passkey pre-auth state. PR:N - under the default PAM responder posture in this tree, the crafted request path does not require elevated privileges or prior authorization to the vulnerable code path; restricting responder access to trusted users reduces reachability. UI:N - no user interaction is required once the crafted request is sent. S:U - the crash occurs within the PAM responder's own security scope. C:N - no confidentiality impact was established. I:N - no integrity impact was established. A:H - successful exploitation can crash sssdpam and disrupt authentication handling on the host. Impact: Moderate. Under Red Hat severity guidance, this is best classified as Moderate because it can disrupt availability of an authentication responder, but the available evidence supports only a local denial of service, not remote reachability, privilege escalation, or confidentiality/integrity compromise. The issue is also conditional on passkey support being built and enabled. Embargo: no Reason: This is a local denial-of-service issue with straightforward mitigations, no demonstrated confidentiality or integrity impact, and no evidence of remote exploitation. Public disclosure without embargo is appropriate. Acknowledgement: Aisle Research Vulnerability Details: passkeykerberos() validates that the attacker-controlled passkey blob contains non-NULL prompt and key fields, but it does not verify that pctx->pktabledata exists before dereferencing pctx->pktabledata->table: c if (prompt == NULL || key == NULL) { DEBUG(SSSDBGOPFAILURE, "Passkey prompt and key are missing or invalid.\n"); return EIO; } data = sssptrhashlookup(pctx->pktabledata->table, key, struct pkchilduserdata); if (data == NULL) { DEBUG(SSSDBGOPFAILURE, "Failed to lookup passkey authtok\n"); return EIO; } That state is allocated in savepasskeydata(), which is reached from passkey pre-auth response handling: c pctx->pktabledata = talloczero(tmpctx, struct pampasskeytabledata); if (pctx->pktabledata == NULL) { return ENOMEM; } if (pctx->pktabledata->table == NULL) { pctx->pktabledata->table = sssptrhashcreate(pctx->pktabledata, NULL, NULL); if (pctx->pktabledata->table == NULL) { ret = ENOMEM; goto done; } } The authenticate path can still dispatch to passkeykerberos() based on token type alone: c #ifdef BUILDPASSKEY if ((pd->cmd == SSSPAMAUTHENTICATE)) { if (maydopasskeyauth(pctx, pd)) { if (sssauthtokgettype(pd->authtok) == SSSAUTHTOKTYPEPASSKEYKRB) { ret = passkeykerberos(pctx, preq->pd, preq); goto done; } else if ((sssauthtokgettype(pd->authtok) == SSSAUTHTOKTYPEPASSKEY) || (sssauthtokgettype(pd->authtok) == SSSAUTHTOKTYPEEMPTY)) { ret = passkeylocal(cctx, cctx->ev, pctx, preq, pd); The request parser also accepts SSSAUTHTOKTYPEPASSKEYKRB directly from client input: c case SSSAUTHTOKTYPEPASSKEY: case SSSAUTHTOKTYPEPASSKEYKRB: case SSSAUTHTOKTYPEPASSKEYREPLY: case SSSAUTHTOKTYPEPAMSTACKED: ret = sssauthtokset(tok, authtokentype, authtokendata, authtokenlength); break; As a result, a crafted local SSSPAMAUTHENTICATE request can select the passkey-Kerberos path without first populating pktabledata. When that happens, the dereference of pctx->pktabledata->table triggers a NULL pointer dereference and crashes sssdpam. The available evidence supports availability impact only. Steps to reproduce: 1. Use a build with passkey support enabled (BUILDPASSKEY) and with pampasskeyauth = true. 2. Connect to the PAM responder UNIX socket (.../pipes/pam). 3. Send a protocol v3 SSSPAMAUTHENTICATE request with authtok type SSSAUTHTOKTYPEPASSKEYKRB, a passkey blob containing non-NULL prompt and key fields, and no prior successful SSSPAMPREAUTH that would populate pktabledata. 4. Observe sssdpam crash from the NULL dereference at pctx->pktabledata->table in passkeykerberos(). Mitigation: If passkey authentication is not required, disable pampasskeyauth to remove the vulnerable path. Where operationally feasible, restrict PAM responder access to explicitly trusted users instead of relying on the default trusted-user posture. These measures reduce or remove reachability but do not replace a code fix. Proposed Fix: Add a guard before dereferencing pctx->pktabledata->table and return an error when passkey Kerberos state has not been initialized. diff diff --git a/src/responder/pam/pamsrvpasskey.c b/src/responder/pam/pamsrvpasskey.c — a/src/responder/pam/pamsrvpasskey.c +++ b/src/responder/pam/pamsrvpasskey.c @@ -144,6 +144,13 @@ errnot passkeykerberos(struct pamctx pctx, return EIO; } + if (pctx->pktabledata == NULL || pctx->pktabledata->table == NULL) { + DEBUG(SSSDBGOPFAILURE, + "Passkey KRB state table missing (pre-auth state not initialized).\n"); + return EIO; + } + data = sssptrhashlookup(pctx->pktabledata->table, key, struct pkchilduserdata); if (data == NULL) { ------ This report was generated using AI technology. Always review AI-generated content prior to use

AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: NSS responder length underflow in packet parsing (ssspacketgetbody) enables local OOB read / crash: undersized client-controlled packet lengths can underflow the computed body length and drive an out-of-bounds read in NSS request parsing, likely crashing the responder. Requirements to exploit: An attacker needs the ability to run a local process on a system running the NSS responder and to connect to its UNIX socket and send a request with len < 16. In the reviewed tree, NSS is initialized with SCKTRSPUMASK, and the peer-UID gate is only applied when alloweduids is configured; deployment-specific socket ACLs or socket-activation settings may still reduce which local users can reach the socket. Component affected: sssd-2.12.0-1.el10, NSS responder packet parsing in src/responder/common/responderpacket.c (ssspacketrecv(), ssspacketgetbody()) and src/responder/nss/nssprotocol.c (sssnssprotocolparsename()) 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:N/UI:N/S:U/C:N/I:N/A:H - 5.5 (MEDIUM) AV:L - Exploitation requires local access to the NSS responder UNIX socket. AC:L - The trigger is a short packet header with a client-controlled len smaller than the 16-byte protocol header; no race or uncommon precondition is established. PR:N - Where the NSS socket is reachable, the reviewed tree does not require responder-specific privileges before sending the malformed request; deployment-specific ACLs can reduce reachability. UI:N - No user interaction is required. S:U - The impact stays within the SSSD responder's security scope. C:N - The available materials show an out-of-bounds read but do not demonstrate practical data disclosure. I:N - No integrity impact is demonstrated. A:H - The established effect is a likely responder crash or denial of service in the NSS path. Impact: Moderate. The available evidence supports a low-complexity local denial of service against the NSS responder, not remote compromise, privilege escalation, or a demonstrated confidentiality breach. Under Red Hat's guidance this is more than Low because it can disrupt availability of NSS account lookup functionality on exposed systems, but it is below Important because the currently supported impact is local and availability-focused. Embargo: no Reason: The demonstrated impact is a local responder crash / denial of service with straightforward remediation and practical exposure reduction through local socket access controls. Acknowledgement: Aisle Research Vulnerability Details: The directly observed path is request receipt in ssspacketrecv() followed by NSS request parsing in sssnssprotocolparsename(). ssspacketrecv() accepts a packet once packet->iop >= newlen, but there is no lower-bound check that newlen = SSSNSSHEADERSIZE. ssspacketgetbody() then subtracts SSSNSSHEADERSIZE unconditionally, and the NSS name parser dereferences body[blen - 1] before any length check. With a crafted header such as len=8, blen underflows as sizet and the null-termination test becomes an out-of-bounds read. c int ssspacketrecv(struct ssspacket packet, int fd) { ... packet->iop += rb; if (packet->iop < SSSPACKETCMDOFFSET) { return EAGAIN; } newlen = ssspacketgetlen(packet); if (newlen > packet->memsize) { enum sssclicommand cmd = ssspacketgetcmd(packet); sizet maxrecvsize; ... } if (packet->iop < newlen) { return EAGAIN; } return EOK; } void ssspacketgetbody(struct ssspacket packet, uint8t body, sizet blen) { body = packet->buffer + SSSPACKETBODYOFFSET; blen = ssspacketgetlen(packet) - SSSNSSHEADERSIZE; } errnot sssnssprotocolparsename(struct clictx clictx, const char rawname) { ... ssspacketgetbody(pctx->creq->in, &body, &blen); / If not terminated fail. / if (body[blen - 1] != '\0') { DEBUG(SSSDBGCRITFAILURE, "Body is not null terminated!\n"); return EINVAL; } ... } The likely consequence is responder termination or request failure in the NSS path. The available materials do not establish a reliable confidentiality disclosure, integrity impact, or code execution primitive. The behavior is confirmed in the reviewed sssd-2.12.0 source tree; the available materials do not establish a narrower introduction point or a released fix. Steps to reproduce: 1. Run a system with SSSD active and the NSS responder enabled. 2. As a local user that can reach the NSS responder UNIX socket, connect to the runtime NSS socket path. A common path is /var/lib/sss/pipes/nss. 3. Send an 8-byte request header with len=8 and cmd=SSSNSSGETPWNAM (0x0011): python import socket, struct s = socket.socket(socket.AFUNIX, socket.SOCKSTREAM) s.connect("/var/lib/sss/pipes/nss") s.sendall(struct.pack("<II", 8, 0x0011)) 4. Observe that the responder may close the connection unexpectedly or crash. Under ASAN or Valgrind, the invalid read is expected in the NSS parse path around the body[blen - 1] check. Mitigation: Until a fixed package is available, restrict access to the NSS responder UNIX socket to trusted local users where operationally possible. Where deployment configuration supports it, apply peer-UID restrictions such as alloweduids or equivalent socket ACLs. This reduces reachability but does not correct the parser flaw. Proposed Fix: Add a minimum-length guard in ssspacketrecv() before the packet is accepted as complete. diff diff --git a/src/responder/common/responderpacket.c b/src/responder/common/responderpacket.c index 0000000..0000000 100644 — a/src/responder/common/responderpacket.c +++ b/src/responder/common/responderpacket.c @@ -217,6 +217,12 @@ int ssspacketrecv(struct ssspacket packet, int fd) newlen = ssspacketgetlen(packet); + if (newlen < SSSNSSHEADERSIZE) { + DEBUG(SSSDBGOPFAILURE, + "Refusing undersized packet from fd %d (length %zu bytes)\n", + fd, newlen); + return EINVAL; + } + if (newlen > packet->memsize) { enum sssclicommand cmd = ssspacketgetcmd(packet); sizet maxrecvsize; ------ This report was generated using AI technology. Always review AI-generated content prior to use

AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: Local DoS in PAM responder via out-of-bounds read on zero-length string auth tokens (extractauthtokv2 -> sssauthtoksetstring): a crafted PAM v2/v3 request can pass a zero-length string-backed auth token into an unbounded strlen() on packet-backed memory and may crash the PAM responder. Requirements to exploit: An attacker needs local access to the host and the ability to send a syntactically valid PAM v2/v3 request to the PAM responder socket. In the source tree, the PAM responder uses SCKTRSPUMASK 0111, which makes unprivileged local reachability plausible, although practical exposure can still vary with deployment and service configuration. Component affected: sssd-2.12.0-1.el10, PAM responder request parsing in src/responder/pam/pamsrvcmd.c (extractauthtokv2()), reaching src/util/authtok.c (sssauthtoksetstring()). 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 - The issue is triggered from the local host by sending a crafted PAM request to the responder socket. AC:L - The malformed input is straightforward: a validly framed request with size = 4 and no token bytes for a string-backed auth token type. PR:L - Exploitation requires only an unprivileged local execution context that can connect to the PAM responder socket. UI:N - No victim interaction is required once the attacker can reach the socket. S:U - The impact is confined to the PAM responder's own security scope. C:N - No confidentiality impact is established from the available technical evidence. I:N - No integrity impact is established from the available technical evidence. A:H - The out-of-bounds read can crash the responder and cause a meaningful loss of PAM responder availability. Impact: Moderate. The issue can affect availability for reachable local clients, but it is not a remote flaw, no privilege escalation is shown, and no confidentiality or integrity impact is established. Under the Red Hat severity guidance, that fits Moderate more closely than Important or Critical. Embargo: no Reason: This is a local denial-of-service issue with configuration-dependent reachability and no demonstrated confidentiality, integrity, or privilege-escalation impact. Prompt remediation is more appropriate than embargo handling. Acknowledgement: Aisle Research Vulnerability Details: In extractauthtokv2(), authtokenlength is derived as datasize - sizeof(uint32t). When a PAM v2/v3 request supplies size = 4, the parser accepts authtokenlength == 0 and still passes the packet-backed pointer into sssauthtokset() for the string-backed auth token types SSSAUTHTOKTYPE2FASINGLE, SSSAUTHTOKTYPEOAUTH2, SSSAUTHTOKTYPEPASSKEY, SSSAUTHTOKTYPEPASSKEYREPLY, and SSSAUTHTOKTYPEPAMSTACKED. That path reaches sssauthtoksetstring(), which contains the following logic: c if (len == 0) { len = strlen(str); } else { while (len > 0 && str[len - 1] == '\0') len--; } Here, str points into the PAM request buffer rather than to a guaranteed NUL-terminated string. Valid PAM framing does not provide a nearby terminator for this path; the recorded end marker is SSSENDOFPAMREQUEST 0x4950414d, so strlen() can continue reading beyond the packet boundary until a zero byte is encountered elsewhere in memory. This creates an out-of-bounds read with plausible responder crash behavior, which is sufficient for a local denial of service. The issue is best understood as missing input validation on zero-length typed string tokens leading to an out-of-bounds read. Steps to reproduce: 1. Build SSSD with ASan (-fsanitize=address) for deterministic detection. 2. Send a PAM protocol v2/v3 request with valid SSSSTARTOFPAMREQUEST ... SSSENDOFPAMREQUEST framing. 3. Include SSSPAMITEMAUTHTOK with size = 4, authtokentype = SSSAUTHTOKTYPE2FASINGLE (or SSSAUTHTOKTYPEOAUTH2, SSSAUTHTOKTYPEPASSKEY, SSSAUTHTOKTYPEPASSKEYREPLY, SSSAUTHTOKTYPEPAMSTACKED), and no token bytes. 4. Follow the parser path pamforwarderparsedata() -> pamparseindatav2/v3() -> extractauthtokv2() -> sssauthtokset(..., len=0) -> sssauthtoksetstring() -> strlen() on the request-backed pointer. 5. Under ASan, observe an out-of-bounds read; without ASan, the responder may crash, resulting in a local denial of service. Mitigation: Restrict PAM responder socket access to trusted local clients where possible. Deployments that already prevent unprivileged local clients from reaching the responder reduce exploitability until a code fix is applied. Proposed Fix: Reject zero-length payloads for the affected string-backed auth token types in extractauthtokv2() before they reach sssauthtoksetstring(). diff — a/src/responder/pam/pamsrvcmd.c +++ b/src/responder/pam/pamsrvcmd.c @@ -204,6 +204,18 @@ static int extractauthtokv2(struct sssauthtoken tok, case SSSAUTHTOKTYPE2FA: case SSSAUTHTOKTYPESCPIN: case SSSAUTHTOKTYPESCKEYPAD: + case SSSAUTHTOKTYPEPASSKEYKRB: + ret = sssauthtokset(tok, authtokentype, + authtokendata, authtokenlength); + break; + case SSSAUTHTOKTYPE2FASINGLE: + case SSSAUTHTOKTYPEOAUTH2: + case SSSAUTHTOKTYPEPASSKEY: + case SSSAUTHTOKTYPEPASSKEYREPLY: + case SSSAUTHTOKTYPEPAMSTACKED: + if (authtokenlength == 0) { + return EINVAL; + } ret = sssauthtokset(tok, authtokentype, authtokendata, authtokenlength); break; case SSSAUTHTOKTYPEPASSKEYKRB:

ret = sssauthtokset(tok, authtokentype,

authtokendata, authtokenlength);

break;

A secondary guard in sssauthtoksetstring() to reject len == 0 on untrusted call paths would provide additional defense in depth. ------ This report was generated using AI technology. Always review AI-generated content prior to use

AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: Unbounded NSS Negative Cache Growth Can Cause Local DoS (Memory Exhaustion): an unprivileged local user can trigger large numbers of distinct negative NSS lookups and drive application-level unbounded growth of the in-memory negative cache, potentially exhausting responder memory and disrupting local name-service availability. Requirements to exploit: Unprivileged local access on a system where the sssd NSS responder is active, the responder socket is reachable by local users, and entrynegativetimeout is non-zero (default 15). The attacker must be able to trigger many distinct NSS misses through normal lookup paths. The available evidence does not establish remote exploitability by default. Component affected: sssd-2.12.0-1.el10 NSS responder negative cache in src/responder/common/negcache.c (sssncacheinit(), sssncachecheckstr(), sssncachesetstr()), with local reachability through src/responder/nss/nsssrv.c Version affected: sssd-2.12.0-1.el10 when the NSS responder is active and entrynegativetimeout is non-zero (default 15) 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 - The established attack path requires local access to issue NSS lookups on the host. AC:L - Repeated distinct nonexistent lookups are sufficient; no race or special conditions are required. PR:L - The demonstrated exploit requires an unprivileged local execution context or local account on the system. UI:N - No victim interaction is needed. S:U - The impact remains within the vulnerable component's 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 - Responder memory can grow until service becomes unstable or the process is OOM-killed. Impact: Moderate. The established outcome is a practical local denial of service against the NSS responder, not remote compromise, privilege escalation, or data exposure. Under Red Hat's severity guidance, that is more than Low because it can materially disrupt host functionality in active NSS deployments, but below Important because the supported attack is local-only and availability-focused. Embargo: no Reason: The available evidence supports a local denial of service with operational mitigations and no evidence of remote compromise, confidentiality loss, or privilege escalation. This class of issue can usually be fixed and disclosed without a prolonged embargo. Acknowledgement: Aisle Research Vulnerability Details: In src/responder/common/negcache.c, the negative cache is created as an in-memory TDB and expired entries are only removed lazily when the same key is checked again: c ctx->tdb = tdbopen("memcache", 0, TDBINTERNAL, ORDWR|OCREAT, 0); ... if (expired) { / expired, remove and return no entry / tdbdelete(ctx->tdb, key); ret = ENOENT; } New negative entries are inserted through tdbstore() with no application-level global size or entry bound shown in this path: c ret = tdbstore(ctx->tdb, key, data, TDBREPLACE); Non-permanent negative caching is enabled by default. In src/responder/common/respondercommon.c, the responder reads entrynegativetimeout with a default of 15: c ret = confdbgetint(cdb, CONFDBNSSCONFENTRY, CONFDBNSSENTRYNEGTIMEOUT, 15, &tmpvalue); Local reachability is realistic when the NSS responder is enabled, because the responder defines a public socket umask: c / Public sockets must be readable and writable by anybody on the system. So we set umask to 0111. / #define SCKTRSPUMASK 0111

Based on the available code and reproduction, many distinct nonexistent lookups can accumulate in memory even though each entry has a timeout, because unique keys are not revisited and therefore do not trigger lazy expiry removal. The supported attack path is through successful "not found" handling in the normal cache-request flow, not through malformed packet delivery. There is an operational clear path for the negative cache, but that is a cleanup mechanism rather than a preventive limit. Steps to reproduce: 1. Ensure the system is using the sssd NSS responder and that entrynegativetimeout is non-zero. 2. Monitor responder memory usage, for example: bash watch -n1 'ps -o pid,rss,cmd -C sssdnss' 3. As an unprivileged local user, generate a large number of distinct negative NSS lookups: bash for i in $(seq 1 500000); do getent passwd nosuchuser$i >/dev/null; done 4. Observe steady RSS growth in sssdnss during and after the run. 5. As a control, clear the negative cache through the existing operational path or send SIGHUP to the monitor; this should remove the accumulated negative-cache state and typically relieve the observed memory pressure. Mitigation: Set entrynegativetimeout = 0 to disable non-permanent negative-cache insertions. This reduces exposure but increases backend lookup traffic.

Use the existing negative-cache clear path or restart the responder if memory growth is observed.

Restrict untrusted local users on systems where the NSS responder is exposed and this behavior would be materially disruptive.

Proposed Fix: A minimal hardening approach is to opportunistically prune expired entries before insertion and reject new inserts once a configured maximum entry count is reached. diff diff --git a/src/responder/common/negcache.c b/src/responder/common/negcache.c ... — a/src/responder/common/negcache.c +++ b/src/responder/common/negcache.c @@ -41,10 +41,15 @@ #define NCDOMAINACCTLOCATEPREFIX NCENTRYPREFIX"DOMLOCATE" #define NCDOMAINACCTLOCATETYPEPREFIX NCENTRYPREFIX"DOMLOCATETYPE" +#define NCACHEDEFAULTMAXENTRIES 20000 + struct sssncctx { struct tdbcontext tdb; uint32t timeout; + uint32t maxentries; }; +struct ncacheprunestate { timet now; uint32t alive; }; + typedef int (ncachesetbynamefnt)(struct sssncctx , bool, const char , const char ); @@ -79,6 +84,7 @@ int sssncacheinit(TALLOCCTX memctx, uint32t timeout, if (!ctx->tdb) return errno; ctx->timeout = timeout; + ctx->maxentries = NCACHEDEFAULTMAXENTRIES; ctx = ctx; return EOK; @@ -146,6 +152,36 @@ done: return ret; } +static int ncachepruneexpired(struct tdbcontext tdb, + TDBDATA key, TDBDATA data, void pvt) +{ + struct ncacheprunestate st = tallocgettype(pvt, struct ncacheprunestate); + unsigned long long ts; + char ep = NULL; + + errno = 0; + ts = strtoull((const char )data.dptr, &ep, 10); + if (errno != 0 || ep != '\0') { + return tdbdelete(tdb, key); + } + + if (ts != 0 && ts < (unsigned long long)st->now) { + return tdbdelete(tdb, key); + } + + st->alive++; + return 0; +} + static int sssncachesetstr(struct sssncctx ctx, char str, bool permanent) { + struct ncacheprunestate st = { 0 }; TDBDATA key; TDBDATA data; @@ -167,6 +203,18 @@ static int sssncachesetstr(struct sssncctx ctx, char str, bool permanent) } if (!timest) return ENOMEM; + st.now = time(NULL); + if (tdbtraverse(ctx->tdb, ncachepruneexpired, &st) < 0) { + return EIO; + } + if (st.alive >= ctx->maxentries) { + DEBUG(SSSDBGMINORFAILURE, + "Negative cache limit reached (%u), dropping [%s]\n", + ctx->maxentries, str); + tallocfree(timest); + return ENOSPC; + } + ret = stringtotdbdata(timest, &data); if (ret != EOK) goto done; ------ This report was generated using AI technology. Always review AI-generated content prior to use

AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: Local DoS in PAM GSSAPI flow via stale clictx->statectx pointer (UAF pattern): a successful GSSAPI context completion frees cached per-connection state without clearing the connection pointer, so a later same-socket SSSGSSAPISECCTX request can terminate the PAM responder and disrupt authentication availability. Requirements to exploit: Local access to a system running the affected package, PAM GSSAPI enabled for at least one service, and the ability to drive a GSSAPI exchange to successful context establishment and then send another SSSGSSAPISECCTX request on the same responder connection. Component affected: sssd-2.12.0-1.el10, src/responder/pam/pamsrvgssapi.c, gssapigetstate(), pamcmdgssapisecctxdone() Version affected: sssd-2.12.0-1.el10 when the PAM responder GSSAPI flow is enabled for at least one service 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:H/PR:L/UI:N/S:U/C:N/I:N/A:H - 4.9 (MEDIUM) AV:L - Exploitation requires local access to the PAM responder socket/protocol. AC:H - The vulnerable path depends on PAM GSSAPI being enabled and on reaching successful context establishment on the same connection before sending another SSSGSSAPISECCTX request. PR:L - The described attack model requires a low-privileged local account. UI:N - No separate victim interaction is required once the attacker can issue the protocol requests. S:U - The impact is limited to the PAM responder's 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 - A successful trigger can terminate the responder and deny PAM authentication service until it is restarted. Impact: Moderate. This issue can cause a meaningful availability failure for PAM authentication in affected deployments, but it is local, configuration-dependent, and tied to the successful GSSAPI completion path on the same connection. Under Red Hat's guidance, that is more consistent with Moderate than Important because it is not an easy remote DoS and does not demonstrate confidentiality or integrity compromise. Embargo: no Reason: The issue is local, setup-dependent, and availability-only, with straightforward operational mitigation and no demonstrated confidentiality or integrity impact. Acknowledgement: Aisle Research Vulnerability Details: The PAM responder caches per-connection GSSAPI state in clictx->statectx and reuses it on later requests: c static struct gssapistate gssapigetstate(struct clictx clictx, const char username, struct sssdomaininfo domain) { struct gssapistate state; state = tallocgettype(clictx->statectx, struct gssapistate); if (state != NULL) { return state; } ... clictx->statectx = state; return state; } That cached state is later freed on the callback completion path: c static void pamcmdgssapisecctxdone(struct teventreq req) { ... done: DEBUG(SSSDBGTRACEFUNC, "Returning [%d]: %s\n", ret, sssstrerror(ret)); if (ret == EOK) { ssspacketseterror(pctx->creq->out, EOK); } else { ssscmdsenderror(state->clictx, ret); } ssscmddone(state->clictx, state); } Based on the available code, ssscmddone(state->clictx, state) frees state but does not clear clictx->statectx, leaving a stale per-connection pointer behind. A subsequent SSSGSSAPISECCTX request on the same socket re-enters gssapigetstate() and consults clictx->statectx again. In builds where talloc detects the freed chunk as invalid, this can abort the responder and cause a local denial of service against PAM authentication. The synchronous error path in pamcmdgssapisecctx() ends with ssscmddone(clictx, NULL) and, based on the available code, does not appear to be the vulnerable free. The stale-pointer condition appears tied to the successful callback completion path. Steps to reproduce: 1. Configure PAM GSSAPI for at least one service, for example by including a test service in pamgssapiservices. 2. Connect as a local user to the PAM responder socket and issue SSSGSSAPIINIT. 3. Send SSSGSSAPISECCTX tokens until context establishment succeeds and the callback completion path is reached. 4. Keep the same socket open and send one additional SSSGSSAPISECCTX request. 5. Observe responder crash or abort behavior consistent with stale clictx->statectx reuse in gssapigetstate(). Mitigation: If an immediate code fix is not possible, disable PAM GSSAPI for affected services or otherwise prevent use of the PAM responder's GSSAPI flow. Restarting the PAM responder can restore service after a crash, but it does not remove the underlying bug. Proposed Fix: Clear clictx->statectx before freeing state in pamcmdgssapisecctxdone(). diff diff --git a/src/responder/pam/pamsrvgssapi.c b/src/responder/pam/pamsrvgssapi.c — a/src/responder/pam/pamsrvgssapi.c +++ b/src/responder/pam/pamsrvgssapi.c @@ -1060,6 +1060,10 @@ static void pamcmdgssapisecctxdone(struct teventreq req) ssscmdsenderror(state->clictx, ret); } + if (state->clictx->statectx == state) { + state->clictx->statectx = NULL; + } + ssscmddone(state->clictx, state); } Equivalent hardening in gssapistatedestructor() is also reasonable. ------ This report was generated using AI technology. Always review AI-generated content prior to use

AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: Local DoS in autofs responder via packet length underflow in autofsreadsetautomntentinput: crafted local SSSAUTOFSSETAUTOMNTENT requests with a declared packet length below the 16-byte header can underflow blen and trigger invalid reads that crash or destabilize the autofs responder. Requirements to exploit: A local attacker must be able to connect to the autofs responder UNIX socket and send a malformed SSSAUTOFSSETAUTOMNTENT request whose declared packet length is smaller than SSSNSSHEADERSIZE. Deployments where the autofs responder is disabled or its socket is not reachable to the attacker are not exposed through this path. Component affected: sssd-2.12.0-1.el10, autofs responder request parsing in src/responder/autofs/autofssrvcmd.c (autofsreadsetautomntentinput()), with related packet length handling in src/responder/common/responderpacket.c Version affected: sssd-2.12.0-1.el10 when the autofs responder is enabled and reachable through its local UNIX socket 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.1 (MEDIUM) AV:L - Exploitation is local through the autofs responder UNIX socket. AC:L - The trigger is a single malformed request with a declared length smaller than the 16-byte header. PR:N - No privileges within the vulnerable component are required beyond being able to open the local responder socket. UI:N - No user interaction is needed. S:U - The impact is limited to the same responder process and security scope. C:N - No confidentiality impact is established. I:N - No integrity impact is established. A:H - Crafted input can terminate or destabilize the autofs responder, causing loss of that service. Impact: Moderate. The available evidence supports a locally reachable denial of service against the autofs responder, but not privilege escalation, confidentiality loss, or integrity compromise. Because the issue is local and exposure depends on the autofs responder being enabled and reachable, this fits Red Hat's Moderate rating more closely than Important. Embargo: no Reason: This is a local, service-scoped denial of service with no demonstrated confidentiality or integrity impact, and there is straightforward mitigation by disabling or restricting the affected responder until a fix is available. Acknowledgement: Aisle Research Vulnerability Details: In autofsreadsetautomntentinput(), the request body is used without first ensuring that the computed body length is non-zero and derived from a valid packet length: c ssspacketgetbody(pctx->creq->in, &body, &blen); / if not terminated fail / if (body[blen - 1] != '\0') { return EINVAL; } / If the body isn't valid UTF-8, fail / if (!sssutf8check(body, blen - 1)) { return EINVAL; } Here, blen is derived as the declared packet length minus SSSNSSHEADERSIZE, and the receive path does not reject declared lengths smaller than SSSNSSHEADERSIZE before dispatch. If an attacker supplies a packet whose declared length is less than 16 bytes, blen wraps to a very large sizet. Subsequent use of body[blen - 1] and sssutf8check(body, blen - 1) can then read outside the actual packet buffer and may crash or destabilize the responder. A declared length of exactly 16 produces blen == 0; that case still underflows the UTF-8 length argument, but the clearer crash-prone case is a declared length below 16. Steps to reproduce: 1. Ensure the autofs responder is enabled and its socket is present, typically /var/lib/sss/pipes/autofs. 2. Send a crafted 16-byte header whose declared packet length field is 15 and whose command is 0x00D1 (SSSAUTOFSSETAUTOMNTENT). 3. Run: bash python3 - <<'PY' import socket, struct sock = "/var/lib/sss/pipes/autofs" len=15 (<16), cmd=0x00D1, status=0, reserved=0 pkt = struct.pack("<IIII", 15, 0x00D1, 0, 0) s = socket.socket(socket.AFUNIX, socket.SOCKSTREAM) s.connect(sock) s.sendall(pkt) print("sent") PY

4. Observe responder instability or crash, or an invalid read when tested with ASan/UBSan. The exact manifestation may vary by build and runtime environment. Mitigation: If autofs integration is not required, disable the autofs responder. Otherwise, restrict access to the autofs responder UNIX socket to trusted local users until a fixed package is available. Proposed Fix: Reject undersized packets in the common receive path and reject zero-length autofs request bodies before subtracting 1 from blen. diff diff --git a/src/responder/common/responderpacket.c b/src/responder/common/responderpacket.c — a/src/responder/common/responderpacket.c +++ b/src/responder/common/responderpacket.c @@ -217,6 +217,10 @@ int ssspacketrecv(struct ssspacket packet, int fd) newlen = ssspacketgetlen(packet); + if (newlen < SSSNSSHEADERSIZE) { + return EINVAL; + } + if (newlen > packet->memsize) { enum sssclicommand cmd = ssspacketgetcmd(packet); sizet maxrecvsize; 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 @@ -386,7 +386,7 @@ autofsreadsetautomntentinput(struct clictx clictx, ssspacketgetbody(pctx->creq->in, &body, &blen); / if not terminated fail / if (body[blen - 1] != '\0') { + if (blen == 0 || body[blen - 1] != '\0') { return EINVAL; }

------ This report was generated using AI technology. Always review AI-generated content prior to use