AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: Fail-open in LDAP ppolicy access check when user lookup returns zero results: missing-user LDAP ppolicy lookups can incorrectly return success and cache an allow decision, permitting continued authorization for a deleted or deprovisioned user in affected configurations. Requirements to exploit: SSSD must use accessprovider = ldap with ldapaccessorder including ppolicy or lockout, the target user must still have locally retained SSSD user state, the ppolicy LDAP lookup for that user must return zero entries, and a new access check must reach the online LDAP access path. Component affected: sssd-2.12.0-1.el10, src/providers/ldap/sdapaccess.c, sdapaccessppolicystepdone() Version affected: sssd-2.12.0-1.el10 when SSSD is configured with the LDAP access provider and ldapaccessorder includes ppolicy or lockout Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Not notified. CVSS: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N - 5.3 (MEDIUM) AV:N - The vulnerable authorization path can be reached through normal remote login or access flows that rely on SSSD. AC:L - Once the affected configuration exists, the triggering condition is a zero-result LDAP lookup for the user. PR:L - Exploitation requires prior valid account context; this is not anonymous access. UI:N - No separate user interaction is required. S:U - The flaw affects the same authorization boundary enforced by SSSD. C:L - Successful exploitation can preserve access to information that should no longer be available to the deleted account. I:L - The same stale authorization can permit limited modification of resources available to that account. A:N - The available evidence does not show a direct availability impact. Impact: Moderate. The flaw can preserve access for a deleted or deprovisioned account, which is a real confidentiality and integrity concern, but exploitation depends on a specific non-default LDAP access-control configuration and pre-existing account state. This is a meaningful security issue, but not an easily exploited default-path compromise. Embargo: no Reason: The issue is configuration-dependent, requires prior account context, and has straightforward operational mitigations pending a fix. Acknowledgement: Aisle Research Vulnerability Details: In sdapaccessppolicystepdone(), locked is initialized to false. When the base-scoped LDAP search returns zero results, the function logs that access is being denied but does not set a deny result. Execution then reaches the common tail, where locked == false causes ret = EOK, and the code writes an allow-state cache entry for future checks. c bool locked = false; ... if (numresults < 1) { DEBUG(SSSDBGCONFSETTINGS, "User [%s] was not found with the specified filter. " "Denying access.\n", state->username); } ... if (locked) { DEBUG(SSSDBGTRACEFUNC, "Access denied by online lookup - account is locked.\n"); ret = ERRACCESSDENIED; } else { DEBUG(SSSDBGTRACEFUNC, "Access granted by online lookup - account is not locked.\n"); ret = EOK; } ... tret = sdapsaveusercachebool(state->domain, state->username, SYSDBLDAPACCESSCACHEDLOCKOUT, !locked); The analogous filter path treats numresults < 1 as a deny condition and returns ERRACCESSDENIED, so the ppolicy handling is a fail-open inconsistency. Based on the available evidence, the security consequence is an authorization bypass for previously known users after deletion or deprovisioning, not a broader unauthenticated compromise. Steps to reproduce: 1. Configure SSSD with accessprovider = ldap and ldapaccessorder = ppolicy or ldapaccessorder = lockout. 2. Ensure a test user exists, authenticates once, and remains present in SSSD state so local user lookup still succeeds. 3. Delete or move the user entry in LDAP so the base-scope lookup used by the ppolicy step returns zero results. 4. Perform a new login or access check for that username while the backend is online. 5. Observe a log sequence equivalent to User [...] was not found with the specified filter. Denying access. followed by Access granted by online lookup - account is not locked. 6. Observe that the final decision is success (EOK) and that the cached lockout allow flag is written as true (!locked). Mitigation: Until a fix is available, avoid using ppolicy or lockout as the sole LDAP access decision where rapid deprovisioning enforcement is required. Clearing stale SSSD cache entries when users are removed from LDAP also reduces the exposure window because the reproduced condition depends on locally retained user state. Proposed Fix: Explicitly deny access when the ppolicy lookup returns zero results so the function cannot fall through to the success path or cache an allow decision. diff diff --git a/src/providers/ldap/sdapaccess.c b/src/providers/ldap/sdapaccess.c index 0000000..0000000 100644 — a/src/providers/ldap/sdapaccess.c +++ b/src/providers/ldap/sdapaccess.c @@ -1953,6 +1953,8 @@ static void sdapaccessppolicystepdone(struct teventreq subreq) if (numresults < 1) { DEBUG(SSSDBGCONFSETTINGS, "User [%s] was not found with the specified filter. " "Denying access.\n", state->username); + locked = true; + ret = ERRACCESSDENIED; } else if (results == NULL) { DEBUG(SSSDBGCRITFAILURE, "numresults > 0, but results is NULL\n"); ret = ERRINTERNAL; Setting either locked = true or ret = ERRACCESSDENIED is sufficient; setting both makes the intended deny behavior explicit and prevents an allow-cache write. ------ This report was generated using AI technology. Always review AI-generated content prior to use

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).

AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: OOB Read in autofsreadgetautomntentinput via unchecked effective offset (SSSAUTOFSGETAUTOMNTENT): a crafted local autofs request can trigger a small out-of-bounds read in the responder parser and may crash the autofs responder. Requirements to exploit: A local attacker must be able to connect to the autofs UNIX socket and send a crafted SSSAUTOFSGETAUTOMNTENT request. The autofs responder must be enabled. The reviewed code suggests common deployments expose this socket broadly, but actual reachability still depends on the deployed socket and directory permissions. Component affected: sssd-2.12.0-1.el10, src/responder/autofs/autofssrvcmd.c, autofsreadgetautomntentinput 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:L - 3.3 (LOW) AV:L - exploitation requires local access to the autofs UNIX socket. AC:L - the malformed packet layout is straightforward once the request format is known. PR:N - no additional SSSD-side privilege check for the autofs responder is established in the reviewed code beyond socket reachability. UI:N - no user interaction is required. S:U - the impact is limited to the same responder security scope. C:N - the available evidence does not establish a meaningful confidentiality impact. I:N - the available evidence does not establish an integrity impact. A:L - the technically supported outcome is responder instability or termination from a small out-of-bounds read, not reliable broader service loss. Impact: Low. Under the Red Hat severity guidance, this fits Low rather than Moderate or Important because exploitation is local-only, depends on the autofs responder being enabled and reachable, and the supported impact is limited to a likely responder-only availability issue. The current evidence does not establish privilege escalation, protected data disclosure, or system compromise. Embargo: no Reason: The issue is local-only, the demonstrated impact is limited, and a straightforward fix and operational mitigations are available. The available evidence does not support a need for embargoed handling. Acknowledgement: Aisle Research Vulnerability Details: The parser validates namelen and checks that mapname[namelen] is NUL-terminated, but it does not advance the checked cursor c past mapname before reading cursor and maxentries. c SAFEALIGNCOPYUINT32CHECK(&namelen, body+c, blen, &c); if (namelen == 0 || namelen > blen - c) { return EINVAL; } mapname = (const char )body + c; / if not null-terminated fail / if (mapname[namelen] != '\0') { return EINVAL; } / If the name isn't valid UTF-8, fail / if (!sssutf8check((const uint8t )mapname, namelen - 1)) { return EINVAL; } SAFEALIGNCOPYUINT32CHECK(cursor, body + c + namelen + 1, blen, &c); SAFEALIGNCOPYUINT32CHECK(maxentries, body + c + namelen + 1, blen, &c); SAFEALIGNCOPYUINT32CHECK validates the current cursor value c against blen, but the actual source pointer is whatever the caller passes. In this function, the checked value remains near the start of the buffer while the effective read address includes + namelen + 1. As a result, an attacker can satisfy the macro's bounds check while forcing the first cursor read to start at body + blen. For sufficiently large inputs that also satisfy the second size check, the maxentries read is out of bounds as well. A practical shape is blen = 4 + namelen + 1, with namelen = blen - 5 and the final in-bounds byte set to '\0'. That layout passes the visible parser checks and places the first cursor read exactly at the end of the request body. The technically supported consequence is a small out-of-bounds read with possible responder crash or instability; reliable confidentiality or integrity impact is not established. The reviewed code also indicates that the autofs responder uses SSSAUTOFSSOCKETNAME with SCKTRSPUMASK (0111), and the available build/install context commonly creates the pipe directory with mode 0775. No autofs-specific alloweduids restriction is evident in the reviewed path. This suggests unprivileged local reachability in common deployments, although final exposure still depends on runtime packaging and filesystem permissions. Steps to reproduce: 1. Enable and start the autofs responder so the autofs UNIX socket is present, typically at /var/lib/sss/pipes/autofs. 2. Connect to that socket and send command SSSAUTOFSGETAUTOMNTENT (0x00D2) with a body containing uint32t namelen, mapname bytes, one trailing '\0', and no valid trailing cursor or maxentries fields. 3. Choose the body so the early checks pass but the first cursor read begins at the end of the buffer: set blen = 4 + namelen + 1, set namelen = blen - 5, and ensure the final in-bounds byte is '\0'. 4. Observe the out-of-bounds read when cursor is parsed from body + c + namelen + 1, which resolves to body + blen for the first read. Sanitized builds should report the access immediately; non-sanitized builds may terminate the responder or show instability depending on allocator and memory layout. Mitigation: Disable the autofs responder where it is not required. If it must remain enabled, restrict access to the autofs socket and its containing directory to trusted local users until a fixed build is available. Proposed Fix: Advance c past mapname and its terminating NUL before parsing cursor and maxentries. diff diff --git a/src/responder/autofs/autofssrvcmd.c b/src/responder/autofs/autofssrvcmd.c index 000000000..000000000 100644 — a/src/responder/autofs/autofssrvcmd.c +++ b/src/responder/autofs/autofssrvcmd.c @@ -574,8 +574,10 @@ autofsreadgetautomntentinput(struct clictx clictx, return EINVAL; } SAFEALIGNCOPYUINT32CHECK(cursor, body + c + namelen + 1, blen, &c);

SAFEALIGNCOPYUINT32CHECK(maxentries, body + c + namelen + 1, blen, &c); + c += namelen + 1; + + SAFEALIGNCOPYUINT32CHECK(cursor, body + c, blen, &c); + SAFEALIGNCOPYUINT32CHECK(maxentries, body + c, blen, &c); mapname = mapname;

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

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.

AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: OOB Read in sssauthunpackpasskeyblob from Unbounded Parsing of SSSAUTHTOKTYPEPASSKEYKRB: a malformed length-delimited passkey blob that omits required in-bounds NUL terminators can be parsed past the provided buffer, causing a locally triggerable out-of-bounds read and likely denial of service in the SSSD PAM responder. Requirements to exploit: Local access to a system using the SSSD PAM responder, plus the ability to submit a crafted SSSAUTHTOKTYPEPASSKEYKRB blob without in-bounds NUL terminators. The available code context indicates this parsing occurs during PAM request handling before later trust-based restrictions, so ordinary local triggering appears plausible in default deployments. Component affected: sssd-2.12.0-1.el10, src/util/authtok.c, sssauthunpackpasskeyblob(); attacker-controlled ingress is via the PAM responder path in src/responder/pam/pamsrvcmd.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:N/UI:N/S:U/C:N/I:N/A:H - 5.5 (MEDIUM) AV:L - Exploitation requires local access to a system that can reach the SSSD PAM responder. AC:L - The malformed input is straightforward: the attacker supplies a passkey blob with missing in-bounds '\0' terminators. PR:N - Available evidence indicates the PAM responder socket is intended to be reachable by ordinary local PAM clients and the affected parsing occurs before trust-based restrictions; deployments that further restrict local access may reduce exposure. UI:N - No separate user interaction is required once the crafted request is sent. S:U - The impact is confined to the vulnerable SSSD component. C:N - No confidentiality impact is established from the available evidence. I:N - No integrity impact is established from the available evidence. A:H - The demonstrated outcome is an out-of-bounds read that can crash or destabilize the authentication responder path. Impact: Moderate. Based on Red Hat's severity guidance, this issue has a credible local availability impact in a core authentication component, but the established effect is not remote, does not show privilege escalation, and does not demonstrate system compromise or arbitrary code execution. That makes it more serious than Low, but not a fit for Important or Critical. Embargo: no Reason: The current evidence supports a local denial-of-service issue with no demonstrated confidentiality, integrity, or code execution impact, and moderate/low issues of this type typically do not require embargo handling. Acknowledgement: Aisle Research Vulnerability Details: sssauthunpackpasskeyblob() parses a passkey blob as a sequence of C strings, but it receives only const uint8t blob and no length parameter. The function therefore trusts in-band '\0' terminators and walks past the caller-provided buffer if they are missing. c errnot sssauthunpackpasskeyblob(TALLOCCTX memctx, const uint8t blob, char prompt, char key, char pin) { sizet len = 0; ... prompt = tallocstrdup(memctx, (const char ) blob + len); len += strlen(prompt) + 1; key = tallocstrdup(memctx, (const char ) blob + len); len += strlen(key) + 1; ... } extractauthtokv2() accepts authtokendata together with authtokenlength, and the SSSAUTHTOKTYPEPASSKEYKRB path passes that length into sssauthtoksetpasskeyfromblob(tok, data, len). However, sssauthtoksetpasskeyfromblob() then calls sssauthunpackpasskeyblob(tmpctx, data, &prompt, &key, &pin);, so the explicit length is discarded before parsing. By contrast, sssauthunpack2fablob() and sssauthunpackscblob() both take bloblen and validate bounds. The available materials establish an out-of-bounds read and a realistic responder crash. An information disclosure effect is theoretically possible for this bug class, but no practical disclosure path is demonstrated here, so the supported impact is local denial of service. Steps to reproduce: 1. Build sssd-2.12.0-1.el10 with AddressSanitizer enabled, for example with -fsanitize=address. 2. Add a cmocka test under src/tests/cmocka/testauthtok.c that calls sssauthtokset(tok, SSSAUTHTOKTYPEPASSKEYKRB, blob, bloblen). 3. Use a blob with no '\0' inside bloblen, for example { 't','r','u','e','K','E','Y','D','A','T','A' } with bloblen = 11. 4. Run the affected unit test. 5. Observe an ASan invalid read originating from strlen()/tallocstrdup() in sssauthunpackpasskeyblob(). This reproducer uses only local code paths and does not depend on external services. Mitigation: No complete runtime mitigation is established from the available information. Until a fixed package is available, reducing access to the local PAM responder interface to trusted users can lower exposure where that is operationally possible, but default responder permissions are designed to allow ordinary local PAM clients. Proposed Fix: Pass the blob length into sssauthunpackpasskeyblob() and replace unbounded string parsing with memchr()-bounded extraction so the passkey parser behaves like the other bounded blob unpackers. diff diff --git a/src/util/authtok.c b/src/util/authtok.c index 0000000..0000000 100644 — a/src/util/authtok.c +++ b/src/util/authtok.c @@ -690,21 +690,43 @@ errnot sssauthunpackpasskeyblob(TALLOCCTX memctx, const uint8t blob, + const uint8t blob, sizet bloblen, char prompt, char key, char pin) {

sizet len = 0; + const uint8t p = blob; + sizet rem = bloblen; + const uint8t end; + sizet flen; char prompt; char key; char pin;

prompt = tallocstrdup(memctx, (const char ) blob + len); + if (blob == NULL || prompt == NULL || key == NULL || pin == NULL) { + return EINVAL; + } + + end = memchr(p, '\0', rem); + if (end == NULL) return EINVAL; + flen = (sizet)(end - p); + prompt = tallocstrndup(memctx, (const char )p, flen); if (prompt == NULL) return ENOMEM;

len += strlen(prompt) + 1; + p += flen + 1; rem -= flen + 1;

key = tallocstrdup(memctx, (const char ) blob + len); + end = memchr(p, '\0', rem); + if (end == NULL) { tallocfree(prompt); return EINVAL; } + flen = (sizet)(end - p); + key = tallocstrndup(memctx, (const char )p, flen); if (key == NULL) { tallocfree(prompt); return ENOMEM; }

len += strlen(key) + 1; + p += flen + 1; rem -= flen + 1;

if ((strcasecmp(prompt, "true") == 0)) { pin = tallocstrdup(memctx, (const char ) blob + len); + end = memchr(p, '\0', rem); + if (end == NULL) { + tallocfree(prompt); + tallocfree(key); + return EINVAL; + } + flen = (sizet)(end - p); + pin = tallocstrndup(memctx, (const char )p, flen); if (pin == NULL) { tallocfree(prompt); tallocfree(key); @@ -792,7 +814,7 @@ static errnot sssauthtoksetpasskeyfromblob(struct sssauthtoken tok,

ret = sssauthunpackpasskeyblob(tmpctx, data, &prompt, &key, &pin); + ret = sssauthunpackpasskeyblob(tmpctx, data, len, &prompt, &key, &pin); @@ -854,7 +876,8 @@ errnot sssauthtokgetpasskey(TALLOCCTX memctx,

ret = sssauthunpackpasskeyblob(memctx, tok->data, &prompt, &key, &pin); + ret = sssauthunpackpasskeyblob(memctx, tok->data, tok->length, + &prompt, &key, &pin);

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

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).

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

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.

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

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. 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.

AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: Access-Control Bypass: shadowExpire=0 Not Treated as Expired in LDAP Shadow Expire Check: an LDAP account marked with shadowExpire=0 can still pass SSSD's shadow-based expiration check and continue authenticating in affected configurations. Requirements to exploit: The attacker needs valid credentials for the affected LDAP account, and the deployment must explicitly enable the LDAP shadow-expire path with accessprovider = ldap, ldapaccessorder including expire, and ldapaccountexpirepolicy = shadow; directory-side controls that independently reject the account would reduce or prevent the observed impact. Component affected: sssd-2.12.0-1.el10, LDAP access-control expire path in src/providers/ldap/sdapaccess.c, sdapaccountexpiredshadow() Version affected: sssd-2.12.0-1.el10 when configured with accessprovider = ldap, ldapaccessorder including expire, and ldapaccountexpirepolicy = shadow Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Not notified. CVSS: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N - 5.4 (MEDIUM) AV:N - Reachable through remote authentication services that rely on PAM/SSSD in affected deployments. AC:L - The bypass follows directly from a single comparison in the shadow-expire check. PR:L - Exploitation requires valid credentials for the expired account. UI:N - No separate user interaction is required once the attacker attempts authentication. S:U - The flaw affects the same authorization scope that evaluates account expiry. C:L - It can preserve unauthorized access to information available to the expired account. I:L - It bypasses intended account-expiration enforcement and can preserve access that should have been revoked. A:N - No direct service outage or denial-of-service condition is established. Impact: Moderate. This is a real access-control bypass that can allow continued use of an account after administrators intended it to be expired, but it is configuration-dependent, requires valid account credentials, and does not demonstrate unauthenticated compromise, code execution, or privilege escalation beyond the affected account. Under Red Hat's severity guidance, that is more consistent with Moderate than Important. Embargo: no Reason: The issue depends on a specific LDAP shadow-expiry configuration and an already valid account, and affected deployments can mitigate immediately by avoiding shadowExpire=0 or enforcing expiry on the directory side. Acknowledgement: Aisle Research Vulnerability Details: In the LDAP access-control expire path, sdapaccountexpiredshadow() only denies the account when spexpire > 0: c today = (long) (time(NULL) / (60 60 24)); if (spexpire > 0 && today >= spexpire) { ret = pamaddresponse(pd, SSSPAMSYSTEMINFO, sizeof(SHADOWEXPIREMSG), (const uint8t ) SHADOWEXPIREMSG); if (ret != EOK) { DEBUG(SSSDBGCRITFAILURE, "pamaddresponse failed.\n"); } return ERRACCOUNTEXPIRED; } stringtoshadowpwdays() accepts 0 as a valid parsed value and uses -1 as the no-expiration sentinel, so 0 is not filtered out as an unset value. Because the access check only expires values strictly greater than 0, shadowExpire=0 falls through and access is granted instead of denied. A related LDAP authentication path checks spexpire != -1, which treats 0 as expired and highlights the inconsistency in how the shadow expiration value is handled. Steps to reproduce: 1. Configure an SSSD domain with accessprovider = ldap, ldapaccessorder = expire, and ldapaccountexpirepolicy = shadow. 2. Ensure the target LDAP user has shadowExpire: 0 and otherwise valid authentication credentials. 3. Authenticate to a PAM service backed by SSSD as that user. 4. Observe that access is granted in the affected configuration instead of failing with an expired-account result such as ERRACCOUNTEXPIRED or PAMACCTEXPIRED. Mitigation: Until a fix is available, do not rely on shadowExpire=0 to expire accounts in deployments using ldapaccountexpirepolicy = shadow. Use a positive past day value for shadowExpire, or enforce account disablement or expiration through directory-side controls that do not depend solely on this client-side check. Proposed Fix: The minimal correction is to treat 0 as expired and keep -1 as the only non-expiring sentinel in this code path. diff diff --git a/src/providers/ldap/sdapaccess.c b/src/providers/ldap/sdapaccess.c — a/src/providers/ldap/sdapaccess.c +++ b/src/providers/ldap/sdapaccess.c @@ -420,7 +420,7 @@ static errnot sdapaccountexpiredshadow(struct pamdata pd, if (spexpire > 0 && today >= spexpire) { + if (spexpire >= 0 && today >= spexpire) { ret = pamaddresponse(pd, SSSPAMSYSTEMINFO, sizeof(SHADOWEXPIREMSG), (const uint8t ) SHADOWEXPIREMSG);

------ 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 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: Use-After-Free in KCM TGT Renewal (authdata->ccname lifetime mismatch): a deferred KCM renewal callback retains a shallow pointer to cc->name after the timer's temporary talloc context is freed, resulting in a local use-after-free read with likely KCM responder denial-of-service impact in affected renewal deployments. Requirements to exploit: An authenticated local user on a host using the KCM responder, with a renewable TGT stored in KCM. Reachability depends on builds with KCM renewal support and deployments configured with db = secdb and tgtrenewal = true; the user then waits for the normal renewal window. Component affected: sssd-2.12.0-1.el10, src/responder/kcm/kcmrenew.c, KCM TGT renewal path in kcmcredschecktimes() with deferred use in kcmrenewtgt() / kcmchildreqsetup(). Version affected: sssd-2.12.0-1.el10; reachability depends on builds with KCM renewal support and deployments using the KCM secdb backend with tgtrenewal = 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:H/PR:L/UI:N/S:U/C:N/I:N/A:H - 4.4 (MEDIUM) AV:L - Exploitation requires local access to a host using the affected KCM responder. AC:H - The vulnerable path is gated by non-default renewal configuration, the secdb backend, and renewal timing before the dangling pointer is consumed. PR:L - A regular authenticated local user with access to KCM and a renewable TGT can reach the path in an affected deployment. UI:N - No separate victim interaction is required once the vulnerable configuration is in place. S:U - The impact is confined to the KCM responder's own security scope. C:N - The available evidence does not establish confidentiality impact. I:N - The available evidence does not establish integrity impact. A:H - The demonstrated consequence is service crash or instability in the KCM responder, resulting in denial of service for affected KCM operations. Impact: Moderate. This issue can allow an authenticated local user to cause an availability impact in the KCM responder, but the affected renewal path is disabled by default and appears effectively limited to the secdb backend. No reliable confidentiality, integrity, or privilege-escalation impact is established from the available evidence. Under Red Hat's severity guidance, this is more appropriately Moderate than Important because it is a real denial-of-service issue in an opt-in, less easily exploited configuration rather than an easily reached default-path compromise. Embargo: no Reason: The currently supported impact is local denial of service in a configuration-gated feature path, and exposure can be reduced immediately by leaving tgtrenewal disabled or disabling renewal where it is enabled. This does not appear to warrant embargo. Acknowledgement: Aisle Research Vulnerability Details: In the KCM TGT renewal path, the renewal context stores a shallow pointer to the credential cache name, but the source object is tied to a temporary talloc context that is later freed before the deferred callback uses the pointer: c authdata->ccname = cc->name; ... tallocfree(tmpctx); ... krreq->ccname = tallocasprintf(krreq, "KCM:%s", authdata->ccname); authdata is queued to a deferred immediate callback, so its lifetime extends beyond the timer handler. The credential caches being iterated originate from a list allocated under tmpctx, which is freed after renewal scheduling completes. When the deferred path reaches kcmchildreqsetup(), authdata->ccname can already point to released memory. This is consistent with a CWE-416 use-after-free read and a CWE-664 lifetime management issue. The available material supports denial of service in the KCM responder; it does not establish reliable confidentiality, integrity, or code-execution impact. Steps to reproduce: 1. Build sssd-2.12.0-1.el10 with KCM renewal support enabled. 2. Configure the KCM responder to use db = secdb and tgtrenewal = true. A short renewal interval makes the issue easier to observe. 3. Restart sssd-kcm. 4. As an unprivileged local user, acquire a renewable TGT in KCM, for example by using KRB5CCNAME=KCM:.... 5. Wait until the renewal window is reached so the timer-driven renewal path executes. 6. Let the renewal timer schedule kcmrenewtgt, then allow the timer handler to finish and free tmpctx. 7. Run under ASan or Valgrind and observe an invalid read or use-after-free report when kcmchildreqsetup() formats KCM:%s with authdata->ccname. Mitigation: If KCM ticket renewal is not required, keep tgtrenewal = false, which avoids the affected path. On systems currently using KCM renewal, disabling the renewal feature until a fixed build is available reduces exposure. Proposed Fix: Deep-copy cc->name into authdata before scheduling the deferred callback, and fail cleanly if that allocation cannot be made. diff diff --git a/src/responder/kcm/kcmrenew.c b/src/responder/kcm/kcmrenew.c @@ -579,11 +579,16 @@ static errnot kcmcredschecktimes(TALLOCCTX memctx, authdata->krb5ctx = renewtgtctx->krb5ctx; authdata->upn = tallocstrdup(authdata, clientname); authdata->uid = cc->owner.uid; authdata->gid = cc->owner.gid; authdata->ccname = cc->name; + authdata->ccname = tallocstrdup(authdata, cc->name); if (authdata->upn == NULL) { ret = ENOMEM; DEBUG(SSSDBGCRITFAILURE, "Unable to allocate authdata->upn for renewals\n"); goto done; } + if (authdata->ccname == NULL) { + ret = ENOMEM; + DEBUG(SSSDBGCRITFAILURE, "Unable to allocate authdata->ccname for renewals\n"); + 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: Unbounded Per-Connection Memory Growth in KCM via GETCREDUUIDLIST / DESTROY: a local client can retain stale credential objects in a long-lived KCM connection and exhaust responder memory through repeated STORE / GETCREDUUIDLIST / DESTROY cycles. Requirements to exploit: The KCM responder must be enabled and reachable, and a local user able to connect to the KCM UNIX socket must keep one client connection alive while repeatedly issuing normal KCM requests against a ccache. Component affected: sssd-2.12.0-1.el10 KCM responder credential-table handling in src/responder/kcm/kcmsrvops.c and src/responder/kcm/kcmsrvops.h (kcmcredstotable(), GETCREDUUIDLIST, GETCREDBYUUID, and DESTROY). Version affected: sssd-2.12.0-1.el10 when the KCM responder is enabled and reachable by a local client 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 and the KCM responder socket. AC:L - Once KCM is reachable, the issue is triggered with a straightforward request loop and no unusual preconditions. PR:L - A local account or equivalent local execution context is needed to connect and send requests. UI:N - No victim interaction is required. S:U - The impact is confined to the KCM responder's own security scope. C:N - The available evidence does not show unauthorized disclosure of credential data. I:N - The issue is stale object retention and memory exhaustion, not unauthorized data modification. A:H - Memory can grow without bound for the life of a maintained connection, leading to denial of service. Impact: Moderate. The issue can cause a real availability loss by exhausting KCM responder memory for deployments that rely on KCM, but exploitation is local and depends on KCM being enabled and reachable. The available evidence does not support confidentiality, integrity, privilege-escalation, or remote-compromise impact, which places the issue below Important or Critical under Red Hat's severity guidance. Embargo: no Reason: This is a local, availability-only denial of service with straightforward operational mitigations and no evidence of confidentiality, integrity, or system-compromise impact. Acknowledgement: Aisle Research Vulnerability Details: The KCM responder keeps a per-connection credential cache in conndata->creds. The helper below creates that table if needed, adds or replaces entries by UUID, and reparents each credential under the table with tallocsteal(), but it does not remove credentials that disappeared from backend state: c struct kcmconndata { / Credentials obtained by GETCREDUUIDLIST. We use to improve performance by avoiding ccache lookups in GETCREDBYUUID. / hashtablet creds; };

... static errnot kcmcredstotable(TALLOCCTX memctx, struct kcmcred creds, hashtablet table) { char str[UUIDSTRSIZE]; uuidt uuid; errnot ret; if (table == NULL) { table = sssptrhashcreate(memctx, kcmcredstabledeletecb, NULL); if (table == NULL) { return ENOMEM; } } for (struct kcmcred crd = creds; crd != NULL; crd = kcmccnextcred(crd)) { ... ret = sssptrhashaddoroverride(table, str, crd, struct kcmcred); if (ret != EOK) { return ret; } tallocsteal(table, crd); } return EOK; } GETCREDUUIDLIST and GETCREDBYUUID both repopulate this same connection-scoped table by calling kcmcredstotable(conndata, kcmccgetcred(cc), &conndata->creds);. In the available DESTROY path, the backend ccache is deleted and the operation returns success, but no corresponding clear or prune of conndata->creds is shown. As a result, stale kcmcred objects can remain reachable for the lifetime of the client connection even after the backend ccache is removed. Repeating STORE, GETCREDUUIDLIST, and DESTROY on one kept-alive connection therefore causes per-connection responder memory growth that is not reclaimed until connection teardown or responder restart. Steps to reproduce: 1. Start the KCM responder and connect to /var/run/.heimorg.h5l.kcm-socket using one persistent client connection. 2. Create or select a ccache name on that same connection. 3. STORE a credential blob so a new credential UUID is added. 4. Call GETCREDUUIDLIST for that ccache so conndata->creds is populated. 5. Call DESTROY for the same ccache. 6. Verify backend deletion succeeds, for example by observing a successful DESTROY result and that the ccache is no longer returned on re-query. 7. Repeat steps 2 through 6 on the same kept-alive connection, continuing to send requests so the connection is not dropped as idle. 8. Observe that the KCM process RSS continues to grow and does not return to baseline until the connection is closed or the responder is restarted. Mitigation: Restrict access to the KCM responder to trusted local users where deployment policy permits, and disable KCM on systems that do not require it. If abnormal memory growth is observed, closing abusive client connections or restarting the responder reclaims the retained connection-scoped memory, but these are operational workarounds rather than a fix. Proposed Fix: Rebuild the per-connection credential table from current backend state on each refresh so stale credentials are released instead of accumulating across a long-lived connection. diff diff --git a/src/responder/kcm/kcmsrvops.c b/src/responder/kcm/kcmsrvops.c — a/src/responder/kcm/kcmsrvops.c +++ b/src/responder/kcm/kcmsrvops.c @@ -1098,6 +1098,12 @@ kcmcredstotable(TALLOCCTX memctx, uuidt uuid; errnot ret; + / Rebuild from current backend view to avoid retaining stale credentials + across long-lived client connections. + / + talloczfree(table); + table = NULL; + if (table == NULL) { table = sssptrhashcreate(memctx, kcmcredstabledeletecb, NULL); if (table == NULL) { An alternative implementation would be to prune UUIDs that are no longer present in the current cc->creds set before returning the refreshed table. ------ This report was generated using AI technology. Always review AI-generated content prior to use

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.

AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: Out-of-Bounds Write in SSSD NFS idmap Plugin (sssnfsclient.c) on memcache hit: destination buffer length is checked and ENOBUFS is set, but memcpy() still copies the full cached user or group name into an undersized caller buffer. Requirements to exploit: The NFS idmap plugin from this SRPM must be in use, rpc.idmapd must be configured with Method = sss, and the memcache path must be enabled (memcache = true, the documented default for the plugin). Exploitation then requires a uidtoname or gidtoname lookup that hits memcache and returns a cached pwname or grname longer than the caller-supplied len. The available source does not establish the caller's buffer-sizing policy, so real-world exploitability depends on external caller and deployment behavior. Component affected: sssd-2.12.0-1.el10, NFS libnfsidmap plugin implementation in src/sssclient/nfs/sssnfsclient.c, specifically getuserfrommc() and getgroupfrommc(), reachable from sssnfsuidtoname() and sssnfsgidtoname(). Version affected: sssd-2.12.0-1.el10; reachable when the NFS idmap plugin is built and rpc.idmapd uses Method = sss with memcache = 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:H/PR:L/UI:N/S:U/C:L/I:L/A:H - 6.1 (MEDIUM) AV:L - The issue is established in local plugin usage on a system running the SSSD NFS idmap path; remote exploitability is not demonstrated by the available evidence. AC:H - Triggering requires a specific buffer-length mismatch in an external caller while the memcache path is enabled and hit by lookup traffic. PR:L - A successful attack typically assumes at least an authenticated foothold or equivalent ability to influence relevant identity data and trigger lookups on the affected host. UI:N - No separate user interaction is required once the vulnerable lookup path is reachable. S:U - The memory corruption occurs within the security scope of the idmap process using this plugin. C:L - Limited disclosure from process memory cannot be ruled out once corruption occurs, but broader disclosure is not established. I:L - The out-of-bounds write can alter adjacent process memory, although reliable controlled modification is not shown. A:H - Memory corruption in the lookup path can crash or destabilize the idmap process handling these requests. Impact: Moderate. This is a real out-of-bounds write, but it does not fit Red Hat's Important or Critical categories on the available evidence because easy remote exploitation and reliable system compromise are not established. Exploitability depends on a specific build and runtime configuration, use of the SSSD NFS idmap plugin, the memcache-backed lookup path, and a caller-supplied buffer that is shorter than the cached name. That aligns more closely with Red Hat's Moderate rating for flaws that can affect confidentiality, integrity, or availability under certain circumstances or in less common configurations. The current evidence does not support claiming reliable privilege escalation or code execution from this flaw alone. Embargo: no Reason: The issue appears to be Moderate and configuration-dependent, and there is a straightforward mitigation by disabling the vulnerable memcache path until a fix is available. Acknowledgement: Aisle Research Vulnerability Details: In both getuserfrommc() and getgroupfrommc(), the code detects that the cached reply is larger than the destination buffer and sets rc = ENOBUFS, but it does not stop before copying. As a result, a memcache hit with pwnamelen > len or grnamelen > len still executes memcpy() and writes past the end of the caller buffer. c pwnamelen = strlen(pwd.pwname) + 1; if (pwnamelen > len) { IDMAPLOG(0, ("%s: reply too long; pwnamelen=%lu, len=%lu", func, pwnamelen, len)); rc = ENOBUFS; } memcpy(name, pwd.pwname, pwnamelen); c grnamelen = strlen(grp.grname) + 1; if (grnamelen > len) { IDMAPLOG(0, ("%s: reply too long; grnamelen=%lu, len=%lu", func, grnamelen, len)); rc = ENOBUFS; } memcpy(name, grp.grname, grnamelen); The affected code is at src/sssclient/nfs/sssnfsclient.c:179-185 and src/sssclient/nfs/sssnfsclient.c:220-226. The trigger path is sssnfsuidtoname() -> getuserfrommc() and sssnfsgidtoname() -> getgroupfrommc(). The unsafe write inside the plugin is direct and unconditional once an oversized memcache result is returned. The exact sizing policy for len is external to these functions, so practical exploitability depends on caller behavior. Steps to reproduce: 1. Build with ASan (-fsanitize=address) and include the NFS idmap plugin (BUILDNFSIDMAP path). 2. Configure rpc.idmapd to use the SSSD plugin (Method = sss) and keep memcache = true (default in sssrpcidmapd.5.xml). 3. Ensure memcache has a user or group name longer than the destination buffer supplied by the caller. 4. Trigger uidtoname or gidtoname resolution so the memcache path is used. 5. At the memcpy() sites above, verify pwnamelen > len or grnamelen > len and observe the out-of-bounds write or ASan report. Mitigation: If an immediate fix is not available, set memcache = false for the SSSD rpc.idmapd plugin so lookups avoid getuserfrommc() and getgroupfrommc(), which are the vulnerable paths. If that is not acceptable, avoid using Method = sss for rpc.idmapd until a fixed build is available. Proposed Fix: Abort the memcache-hit path before memcpy() when the returned name does not fit in the caller buffer. diff diff --git a/src/sssclient/nfs/sssnfsclient.c b/src/sssclient/nfs/sssnfsclient.c @@ -179,10 +179,11 @@ static int getuserfrommc(char name, sizet len, uidt uid) if (pwnamelen > len) { IDMAPLOG(0, ("%s: reply too long; pwnamelen=%lu, len=%lu", func, pwnamelen, len)); rc = ENOBUFS; + goto done; } IDMAPLOG(1, ("found uid %i in memcache", uid)); memcpy(name, pwd.pwname, pwnamelen); @@ -220,10 +221,11 @@ static int getgroupfrommc(char name, sizet len, idt gid) if (grnamelen > len) { IDMAPLOG(0, ("%s: reply too long; grnamelen=%lu, len=%lu", func, grnamelen, len)); rc = ENOBUFS; + goto done; } IDMAPLOG(1, ("found gid %i in memcache", gid)); memcpy(name, grp.grname, grnamelen); ------ This report was generated using AI technology. Always review AI-generated content prior to use

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).

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

AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: LDAP Access Control Bypass When pwdexpirepolicywarn Precedes Restrictive Rules in ldapaccessorder: an expired-password warning is converted into a successful PAM result before later LDAP access rules run, allowing configured filter, host, or similar restrictive checks to be bypassed. Requirements to exploit: A valid LDAP-backed account whose password is expired, an LDAP deployment using accessprovider = ldap with a compatible password-expiration policy, ldapaccessorder placing pwdexpirepolicywarn before restrictive rules, and a non-password authentication path such as SSH public key that still invokes SSSD account/access checks. Component affected: sssd-2.12.0-1.el10, LDAP access-control evaluation in src/providers/ldap/sdapaccess.c (sdapaccesschecknextrule()) and success mapping in src/providers/ldap/ldapaccess.c (sdappamaccesshandlerdone()). Version affected: sssd-2.12.0-1.el10 in LDAP deployments where ldapaccessorder places pwdexpirepolicywarn before restrictive rules. Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Not notified. CVSS: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N - 6.8 (MEDIUM) AV:N - reachable over the network through services that rely on SSSD LDAP account/access checks, such as SSH. AC:H - exploitation depends on a specific non-default rule ordering, an expired-password state, and a compatible non-password authentication path. PR:L - the attacker needs a valid account that can authenticate to the target service. UI:N - no separate victim interaction is required once the attacker initiates authentication. S:U - the impact remains within the vulnerable service's own security scope. C:H - a successful bypass can expose data on systems or services that should have remained inaccessible under filter, host, or rhost restrictions. I:H - the same bypass can permit unauthorized actions within those protected systems or services. A:N - the flaw does not inherently reduce availability. Impact: Moderate. This is a real authorization bypass with meaningful confidentiality and integrity consequences where LDAP access rules are used as security boundaries, but exploitation requires a valid account, an expired-password condition, and a specific non-default ldapaccessorder configuration. That fits a security flaw that can compromise resources under certain circumstances, while being less easily exploitable than a default-path or broadly reachable access-control failure. Embargo: no Reason: the issue is configuration-dependent, requires an already valid account, and can be mitigated immediately by reordering or removing pwdexpirepolicywarn from the front of ldapaccessorder. Acknowledgement: Aisle Research Vulnerability Details: The documented purpose of pwdexpirepolicywarn is to warn while still allowing login. The issue here is narrower: in the LDAP access path, that warning state terminates ordered rule evaluation before later restrictive checks are reached. In sdapaccesschecknextrule(), rule processing only continues while ret == EOK; when LDAPACCESSEXPIREPOLICYWARN converts an expired password into ERRPASSWORDEXPIREDWARN, the loop stops and returns that non-EOK status. c while (ret == EOK) { ... case LDAPACCESSEXPIREPOLICYWARN: ret = performpwexpirepolicy(state, state->domain, state->pd, state->accessctx->type, state->accessctx->idctx->opts); if (ret == ERRPASSWORDEXPIRED) { ret = ERRPASSWORDEXPIREDWARN; } break; ... } state->currentrule++; } return ret; That returned status is then treated as success in sdappamaccesshandlerdone(), which maps both EOK and ERRPASSWORDEXPIREDWARN to PAMSUCCESS. In deployments using an ordered configuration such as pwdexpirepolicywarn,filter,host, later filter, host, or rhost checks are skipped entirely, so an expired-password user can be accepted by the warning path before the restrictive rules run. Steps to reproduce: 1. Configure an LDAP-backed SSSD domain with accessprovider = ldap, ldappwdpolicy = shadow (or mitkerberos), ldapaccessorder = pwdexpirepolicywarn,filter,host, and a restrictive ldapaccessfilter or host rule that should deny the test user. 2. Ensure the test user's password is marked expired in the LDAP attributes used by the selected password policy. 3. Authenticate through a non-password method that still invokes account/access checks, such as SSH public key login. 4. Expected result: a later filter or host rule denies access. Actual result: the warning path returns ERRPASSWORDEXPIREDWARN, the handler maps it to PAMSUCCESS, and the later restrictive rules are not evaluated. Mitigation: Until a fix is available, do not place pwdexpirepolicywarn before restrictive entries in ldapaccessorder. If warning behavior is still required, place it after filter, host, rhost, or other denial-capable rules, or use pwdexpirepolicyreject where expired accounts should not continue through the access chain. Proposed Fix: Record the warning state, continue evaluating the remaining ordered rules, and only return ERRPASSWORDEXPIREDWARN after all configured access rules have passed. diff diff --git a/src/providers/ldap/sdapaccess.c b/src/providers/ldap/sdapaccess.c — a/src/providers/ldap/sdapaccess.c +++ b/src/providers/ldap/sdapaccess.c @@ struct sdapaccessreqctx { @@ sizet currentrule; enum sdapaccesscontroltype actype; + bool pwexpirewarnseen; }; @@ state->conn = conn; state->currentrule = 0; + state->pwexpirewarnseen = false; @@ static errnot sdapaccesschecknextrule(struct sdapaccessreqctx state, case LDAPACCESSEMPTY: / we are done with no errors /

return EOK; + / all rules passed; preserve warn semantics if seen / + return state->pwexpirewarnseen ? ERRPASSWORDEXPIREDWARN : EOK; @@ case LDAPACCESSEXPIREPOLICYWARN: ret = performpwexpirepolicy(state, state->domain, state->pd, state->accessctx->type, state->accessctx->idctx->opts); if (ret == ERRPASSWORDEXPIRED) {

ret = ERRPASSWORDEXPIREDWARN; + state->pwexpirewarnseen = true; + ret = EOK; } break;

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

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.

AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: NULL Pointer Dereference in expandsid() ({sid} / {sid.rid}) Can Crash SSSD in LDAPU1 Certmap Flows: a missing NULL check allows a certificate without Microsoft SID extension OID 1.3.6.1.4.1.311.25.2 to drive a NULL sidext into SID-based LDAPU1 certmap expansion and crash the SSSD certificate-mapping path. Requirements to exploit: The deployment must use certificate mapping with an LDAPU1 maprule that expands {sid} or {sid.rid}, and the attacker must be able to supply a syntactically valid certificate to that path. The certificate must omit OID 1.3.6.1.4.1.311.25.2. The available evidence supports denial of service where certificate input is attacker-controlled; it does not establish broader impact. Component affected: sssd-2.12.0-1.el10, certificate mapping in src/lib/certmap/ssscertmap.c (expandsid() / expandtemplate()) together with SID extraction in src/lib/certmap/ssscertcontentcrypto.c (getsidext()). Version affected: sssd-2.12.0-1.el10 when an LDAPU1 certmap rule uses {sid} or {sid.rid}. Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Not notified. CVSS: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H - 5.9 (MEDIUM) AV:N - In deployments exposing certificate-authentication or certificate-lookup flows to remote clients, the attacker can reach the vulnerable mapping path over the network. AC:H - Exploitation depends on a non-default but supported LDAPU1 SID-based certmap rule and on a certificate that omits the SID extension. PR:N - No prior privileges are required once the affected certmap flow is reachable. UI:N - No victim interaction is required; the service evaluates the certificate automatically. S:U - The crash affects the same SSSD 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 - The NULL dereference can terminate the SSSD process handling certificate mapping, denying authentication or lookup service until recovery. Impact: Moderate. Red Hat rates remote denial of service issues as Important when they can easily affect availability, but this case depends on a specific LDAPU1 SID-based certmap configuration rather than a default or broadly expected setup. The evidence supports availability impact only, so Moderate is a better fit. Embargo: no Reason: This is a configuration-dependent denial of service with straightforward mitigation and a small, self-contained fix. The available evidence does not show confidentiality, integrity, or code-execution impact. Acknowledgement: Aisle Research Vulnerability Details: Certificate parsing can succeed even when the Microsoft SID extension is absent. In that case getsidext() returns success without populating sidext, and expandtemplate() passes that pointer directly into expandsid(). The materials most directly establish the crash path for {sid.rid} via strrchr(NULL, '-'). {sid} should be covered by the same guard because the same NULL sid is also passed into tallocstrdup(ctx, sid). Supporting material indicates SID-based expansion is part of supported LDAPU1 handling, so this is a reachable configuration path rather than dead code. Relevant CWE: CWE-476. c static int expandsid(struct ssscertmapctx ctx, const char attrname, const char sid, char expanded) { char exp; char sep; if (attrname == NULL) { exp = tallocstrdup(ctx, sid); } else if (strcasecmp(attrname, "rid") == 0) { sep = strrchr(sid, '-'); if (sep == NULL || sep[1] == '\0') { CMDEBUG(ctx, "Unsupported SID string [%s].", sid); return EINVAL; } exp = tallocstrdup(ctx, sep+1); } else { CMDEBUG(ctx, "Unsupported attribute name [%s].", attrname); return EINVAL; } ... } ... } else if (strcmp("sid", parsedtemplate->name) == 0) { ret = expandsid(ctx, parsedtemplate->attrname, certcontent->sidext, &exp); } ... idx = X509getextbyOBJ(cert, sidextoid, -1); ASN1OBJECTfree(sidextoid); if (idx == -1) { / Extension most probably not available, no error. / return 0; } Steps to reproduce: 1. Configure a certmap rule using LDAPU1 SID expansion, for example maprule = LDAPU1:(objectsid={sid.rid}). 2. Ensure that rule is exercised by a real certificate lookup or authentication path, such as PAM, LDAP, or proxy-backed cert mapping. 3. Present a syntactically valid certificate that does not contain OID 1.3.6.1.4.1.311.25.2. 4. Trigger certificate mapping so ssscertmapgetsearchfilter() or ssscertmapexpandmappingrule() evaluates the rule. 5. Observe the NULL dereference in expandsid() and resulting process crash. The clearest reproduction is with {sid.rid}. Mitigation: Until a fix is shipped, avoid LDAPU1 certmap rules that expand {sid} or {sid.rid}. If SID-based mapping is required, reject certificates missing OID 1.3.6.1.4.1.311.25.2 before they reach the affected expansion path. Proposed Fix: Add an early NULL check in expandsid() and return an error when the SID extension is absent, so SID-based LDAPU1 mapping rules fail cleanly instead of dereferencing NULL. diff diff --git a/src/lib/certmap/ssscertmap.c b/src/lib/certmap/ssscertmap.c — a/src/lib/certmap/ssscertmap.c +++ b/src/lib/certmap/ssscertmap.c @@ -580,6 +580,11 @@ static int expandsid(struct ssscertmapctx ctx, const char attrname, char exp; char sep; + if (sid == NULL) { + CMDEBUG(ctx, "SID extension is missing."); + return ENOENT; + } + if (attrname == NULL) { exp = tallocstrdup(ctx, sid); } else if (strcasecmp(attrname, "rid") == 0) { ------ This report was generated using AI technology. Always review AI-generated content prior to use

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.

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

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.

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. 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. 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.

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: 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