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

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

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

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

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

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

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

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

A flaw was found in SSSD. An unprivileged local user can repeatedly request master automount map updates through the autofs responder due to missing authorization checks. This triggers global cache invalidation and forces repeated lookups to backend directory providers, leading to a Denial of Service (DoS) from degraded automount availability and elevated resource consumption.

A flaw was found in SSSD. 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.

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.

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

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

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

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

AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: 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

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

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

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

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

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

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

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

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

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

AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: 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: 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

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

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