CVE-2026-90994: Sssd: sssd: denial of service via malformed pam v1 requests
A flaw was found in sssd, specifically within the PAM (Pluggable Authentication Modules) responder's protocol v1 parser, pamparseindata(). A local client with access to the PAM responder's UNIX socket can exploit this by negotiating protocol v1 and sending an empty or truncated PAM request body. This can trigger an out-of-bounds read, potentially causing the PAM responder to terminate or restart, leading to a local denial of service.
Other sources
AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: Local Out-of-Bounds Read in PAM v1 Parser (pamparseindata) Causing Potential DoS: a local client that negotiates protocol v1 and sends an empty or truncated PAM request body can trigger an out-of-bounds read and may terminate the PAM responder, resulting in local denial of service. Requirements to exploit: Local access to the PAM responder UNIX socket, the ability to negotiate protocol v1 with SSSGETVERSION, and the ability to send a malformed SSSPAMAUTHENTICATE request body. No user interaction is required. If a deployment restricts PAM socket access more tightly than common configurations, practical exploitability is reduced. Component affected: sssd-2.12.0-1.el10 PAM responder in src/responder/pam/pamsrvcmd.c, function pamparseindata() 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:L - 3.9 (LOW) AV:L - The issue is reachable only from a local client that can connect to the PAM responder UNIX socket. AC:L - Triggering the flaw requires only a malformed protocol v1 request body such as an empty or truncated message. PR:N - The vulnerable parser path itself does not require prior authentication, and common PAM socket deployments allow local clients to reach it; stricter socket ACLs would reduce practical risk. UI:N - No human interaction is needed once local socket access is available. S:U - The impact remains within the PAM responder's own security scope. C:N - The available evidence shows an out-of-bounds read, but not disclosure of sensitive data. I:N - No data modification, privilege gain, or integrity impact is established. A:L - The demonstrated outcome is potential local denial of service, but the available evidence does not show a consistently reliable high-impact crash in every malformed-input case. Impact: Moderate. This is a real local memory-safety flaw in a security-sensitive authentication responder, and malformed v1 requests can affect service availability. However, the available evidence supports local denial of service only, with no demonstrated confidentiality or integrity impact, and the failure appears less than maximally reliable, which places it below Red Hat's Important classification. Embargo: no Reason: The issue is local-only, the demonstrated impact is limited to availability, and the remediation is straightforward. Based on Red Hat guidance, this does not appear to require embargoed handling. Acknowledgement: Aisle Research Vulnerability Details: In the PAM responder's protocol v1 parser, pamparseindata() computes last = blen - 1 before validating blen, then repeatedly dereferences body[end++] without first proving end < blen. This creates two supported failure modes: blen == 0 underflows last to SIZEMAX, and truncated v1 string fields can advance end to or beyond the end of the supplied body before the terminator check occurs. c static int pamparseindata(struct pamdata pd, uint8t body, sizet blen) { sizet start; sizet end; sizet last; int ret; last = blen - 1; end = 0; / user name / for (start = end; end < last; end++) if (body[end] == '\0') break; if (body[end++] != '\0') return EINVAL; pd->logonname = (char ) &body[start]; ... } The same unchecked body[end++] pattern is then repeated while parsing service, tty, ruser, and rhost. Protocol version 1 remains registered, and the request dispatch path still selects pamparseindata() when v1 is negotiated, so the vulnerable parser remains reachable through the PAM responder. Based on the available evidence, the expected security effect is an out-of-bounds read that may cause responder termination or restart behavior depending on build hardening and runtime supervision; code execution, data disclosure, and privilege escalation are not established. Steps to reproduce: 1. Build or run the package with ASAN enabled, or run the PAM responder under a debugger. 2. Connect to the PAM responder UNIX socket, typically /var/lib/sss/pipes/pam in standard deployments. 3. Send SSSGETVERSION (0x0001) with body uint32(1) to negotiate protocol v1. 4. On the same connection, send SSSPAMAUTHENTICATE (0x00F1) with either an empty body (blen == 0) or a truncated v1 body that omits one or more required '\0' terminators. 5. Observe an ASAN invalid read or responder termination/restart behavior, depending on build and runtime conditions. Mitigation: Restrict local access to the PAM responder UNIX socket to trusted users where operationally possible. If protocol v1 requests can be avoided in the affected environment, that reduces exposure, but there is no complete mitigation short of patching the v1 parser to reject zero-length and truncated inputs before any out-of-bounds dereference occurs. Proposed Fix: Reject zero-length bodies before evaluating blen - 1, and check end >= blen before each body[end] dereference while parsing the v1 NUL-terminated fields. diff diff --git a/src/responder/pam/pamsrvcmd.c b/src/responder/pam/pamsrvcmd.c index 0000000..1111111 100644 — a/src/responder/pam/pamsrvcmd.c +++ b/src/responder/pam/pamsrvcmd.c @@ -475,6 +475,11 @@ static int pamparseindata(struct pamdata pd, sizet last; int ret; + / Prevent sizet underflow and invalid first dereference / + if (blen == 0) { + return EINVAL; + } + last = blen - 1; end = 0; @@ -482,27 +487,42 @@ static int pamparseindata(struct pamdata pd, / user name / for (start = end; end < last; end++) if (body[end] == '\0') break; if (body[end++] != '\0') return EINVAL; + if (end >= blen || body[end] != '\0') return EINVAL; + end++; pd->logonname = (char ) &body[start];
for (start = end; end < last; end++) if (body[end] == '\0') break; if (body[end++] != '\0') return EINVAL; + if (end >= blen || body[end] != '\0') return EINVAL; + end++; pd->service = (char ) &body[start];
for (start = end; end < last; end++) if (body[end] == '\0') break; if (body[end++] != '\0') return EINVAL; + if (end >= blen || body[end] != '\0') return EINVAL; + end++; pd->tty = (char ) &body[start];
for (start = end; end < last; end++) if (body[end] == '\0') break; if (body[end++] != '\0') return EINVAL; + if (end >= blen || body[end] != '\0') return EINVAL; + end++; pd->ruser = (char ) &body[start];
for (start = end; end < last; end++) if (body[end] == '\0') break; if (body[end++] != '\0') return EINVAL; + if (end >= blen || body[end] != '\0') return EINVAL; + end++; pd->rhost = (char ) &body[start];
------ This report was generated using AI technology. Always review AI-generated content prior to use
— Red Hat
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Implement the proposed fix in pam_parse_in_data(): reject zero-length bodies (blen == 0) before evaluating blen - 1, and add bounds checks (e.g., verify end >= blen before any body[end] dereference) so that the parser never reaches the pattern 'body[end++]' without first proving 'end < blen' for each dereference while parsing protocol v1 NUL-terminated fields.
sssd PAM responder protocol v1 parser (pam_parse_in_data in src/responder/pam/pamsrv_cmd.c) Reject zero-length/truncated PAM request bodies before computing last=end index = If blen == 0 then require end < blen and body[end] == '\0' before any body[end] dereference; also add end >= blen checks before each body[end] check during field parsing; compute last only after validating blen - Compensating control
Restrict local access to the sssd PAM responder UNIX socket at /var/lib/sss/pipes/pam (e.g., tighter socket ACLs / firewalling so only trusted local clients can connect), since triggering requires a local client that can connect and negotiate protocol v1 and send an empty/truncated request body.
- Operational
Observe the PAM responder behavior under malformed-input conditions (e.g., using ASAN invalid read or responder termination/restart behavior) on the connection after sending SSS_GET_VERSION (0x0001) to negotiate protocol v1 and sending SSS_PAM_AUTHENTICATE (0x00F1) with an empty/truncated body, to confirm the mitigation prevents out-of-bounds reads and responder crashes/restarts.
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Systems running the affected sssd PAM responder are exposed when a local client can access its UNIX socket. Deployments that restrict access to that socket more tightly than common configurations have reduced practical exploitability.
What does an attacker need to trigger the denial of service?
An attacker needs local access to the PAM responder UNIX socket, must negotiate protocol v1 using SSS_GET_VERSION, and must send an empty or truncated SSS_PAM_AUTHENTICATE request body. No privileges or user interaction are required.
What happens when exploitation succeeds?
The malformed request can cause an out-of-bounds read in pam_parse_in_data(). This may terminate or restart the PAM responder, causing a local denial of service.