Bug 2478862 (CVE-2026-104042) - CVE-2026-104042 sssd: sssd: Denial of Service via out-of-bounds read in PAM responder
Summary: CVE-2026-104042 sssd: sssd: Denial of Service via out-of-bounds read in PAM r...
Keywords:
Status: NEW
Alias: CVE-2026-104042
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On: 2546260
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-05-18 03:47 UTC by OSIDB Bzimport
Modified: 2026-10-06 00:59 UTC (History)
18 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-05-18 03:47:50 UTC
AI_ONLY_REPORT
package: sssd-2.12.0-1.el10
------
Summary: Local DoS in PAM responder via out-of-bounds read on zero-length  
string auth tokens (extract_authtok_v2 -> sss_authtok_set_string): a  
crafted PAM v2/v3 request can pass a zero-length string-backed auth token  
into an unbounded `strlen()` on packet-backed memory and may crash the PAM  
responder.
Requirements to exploit: An attacker needs local access to the host and the  
ability to send a syntactically valid PAM v2/v3 request to the PAM  
responder socket. In the source tree, the PAM responder uses  
`SCKT_RSP_UMASK 0111`, which makes unprivileged local reachability  
plausible, although practical exposure can still vary with deployment and  
service configuration.
Component affected: `sssd-2.12.0-1.el10`, PAM responder request parsing in  
`src/responder/pam/pamsrv_cmd.c` (`extract_authtok_v2()`), reaching  
`src/util/authtok.c` (`sss_authtok_set_string()`).
Version affected: `sssd-2.12.0-1.el10`
Patch available: no released package fix established; proposed patch  
included below
Version fixed: unknown
Upstream coordination: Not notified.
CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H - 5.5 (MEDIUM)
AV:L - The issue is triggered from the local host by sending a crafted  
PAM request to the responder socket.
AC:L - The malformed input is straightforward: a validly framed request  
with `size = 4` and no token bytes for a string-backed auth token type.
PR:L - Exploitation requires only an unprivileged local execution  
context that can connect to the PAM responder socket.
UI:N - No victim interaction is required once the attacker can reach the  
socket.
S:U - The impact is confined to the PAM responder's own security scope.
C:N - No confidentiality impact is established from the available  
technical evidence.
I:N - No integrity impact is established from the available technical  
evidence.
A:H - The out-of-bounds read can crash the responder and cause a  
meaningful loss of PAM responder availability.
Impact: Moderate. The issue can affect availability for reachable local  
clients, but it is not a remote flaw, no privilege escalation is shown, and  
no confidentiality or integrity impact is established. Under the Red Hat  
severity guidance, that fits Moderate more closely than Important or  
Critical.
Embargo: no
Reason: This is a local denial-of-service issue with  
configuration-dependent reachability and no demonstrated confidentiality,  
integrity, or privilege-escalation impact. Prompt remediation is more  
appropriate than embargo handling.
Acknowledgement: Aisle Research
Vulnerability Details: In `extract_authtok_v2()`, `auth_token_length` is  
derived as `data_size - sizeof(uint32_t)`. When a PAM v2/v3 request  
supplies `size = 4`, the parser accepts `auth_token_length == 0` and still  
passes the packet-backed pointer into `sss_authtok_set()` for the  
string-backed auth token types `SSS_AUTHTOK_TYPE_2FA_SINGLE`,  
`SSS_AUTHTOK_TYPE_OAUTH2`, `SSS_AUTHTOK_TYPE_PASSKEY`,  
`SSS_AUTHTOK_TYPE_PASSKEY_REPLY`, and `SSS_AUTHTOK_TYPE_PAM_STACKED`. That  
path reaches `sss_authtok_set_string()`, which contains the following logic:
```c
if (len == 0) {
len = strlen(str);
} else {
while (len > 0 && str[len - 1] == '\0') len--;
}
```
Here, `str` points into the PAM request buffer rather than to a guaranteed  
NUL-terminated string. Valid PAM framing does not provide a nearby  
terminator for this path; the recorded end marker is  
`SSS_END_OF_PAM_REQUEST` `0x4950414d`, so `strlen()` can continue reading  
beyond the packet boundary until a zero byte is encountered elsewhere in  
memory. This creates an out-of-bounds read with plausible responder crash  
behavior, which is sufficient for a local denial of service. The issue is  
best understood as missing input validation on zero-length typed string  
tokens leading to an out-of-bounds read.
Steps to reproduce:
1. Build SSSD with ASan (`-fsanitize=address`) for deterministic detection.
2. Send a PAM protocol v2/v3 request with valid  
`SSS_START_OF_PAM_REQUEST` ... `SSS_END_OF_PAM_REQUEST` framing.
3. Include `SSS_PAM_ITEM_AUTHTOK` with `size = 4`, `auth_token_type =  
SSS_AUTHTOK_TYPE_2FA_SINGLE` (or `SSS_AUTHTOK_TYPE_OAUTH2`,  
`SSS_AUTHTOK_TYPE_PASSKEY`, `SSS_AUTHTOK_TYPE_PASSKEY_REPLY`,  
`SSS_AUTHTOK_TYPE_PAM_STACKED`), and no token bytes.
4. Follow the parser path `pam_forwarder_parse_data()` ->  
`pam_parse_in_data_v2/v3()` -> `extract_authtok_v2()` ->  
`sss_authtok_set(..., len=0)` -> `sss_authtok_set_string()` -> `strlen()`  
on the request-backed pointer.
5. Under ASan, observe an out-of-bounds read; without ASan, the responder  
may crash, resulting in a local denial of service.
Mitigation: Restrict PAM responder socket access to trusted local clients  
where possible. Deployments that already prevent unprivileged local clients  
from reaching the responder reduce exploitability until a code fix is  
applied.
Proposed Fix: Reject zero-length payloads for the affected string-backed  
auth token types in `extract_authtok_v2()` before they reach  
`sss_authtok_set_string()`.
```diff
— a/src/responder/pam/pamsrv_cmd.c
+++ b/src/responder/pam/pamsrv_cmd.c
@@ -204,6 +204,18 @@ static int extract_authtok_v2(struct sss_auth_token  
*tok,
case SSS_AUTHTOK_TYPE_2FA:
case SSS_AUTHTOK_TYPE_SC_PIN:
case SSS_AUTHTOK_TYPE_SC_KEYPAD:
+    case SSS_AUTHTOK_TYPE_PASSKEY_KRB:
+        ret = sss_authtok_set(tok, auth_token_type,
+                              auth_token_data, auth_token_length);
+        break;
+    case SSS_AUTHTOK_TYPE_2FA_SINGLE:
+    case SSS_AUTHTOK_TYPE_OAUTH2:
+    case SSS_AUTHTOK_TYPE_PASSKEY:
+    case SSS_AUTHTOK_TYPE_PASSKEY_REPLY:
+    case SSS_AUTHTOK_TYPE_PAM_STACKED:
+        if (auth_token_length == 0) {
+            return EINVAL;
+        }
ret = sss_authtok_set(tok, auth_token_type,
auth_token_data, auth_token_length);
break;
   case SSS_AUTHTOK_TYPE_PASSKEY_KRB:

       ret = sss_authtok_set(tok, auth_token_type,

                             auth_token_data, auth_token_length);

       break;
```


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


Note You need to log in before you can comment on or make changes to this bug.