Bug 2478664 (CVE-2026-104044) - CVE-2026-104044 sssd: sssd: Denial of Service via crafted passkey Kerberos authentication request
Summary: CVE-2026-104044 sssd: sssd: Denial of Service via crafted passkey Kerberos au...
Keywords:
Status: NEW
Alias: CVE-2026-104044
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: 2546262 2546258
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-05-18 03:41 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:41:45 UTC
AI_ONLY_REPORT
package: sssd-2.12.0-1.el10
------
Summary: Reachable NULL Pointer Dereference in `passkey_kerberos`  
(`SSS_AUTHTOK_TYPE_PASSKEY_KRB`) causing Local DoS: crafted local PAM  
authentication requests can reach `passkey_kerberos()` before passkey  
pre-auth state is initialized and crash `sssd_pam`.
Requirements to exploit: Local access to the PAM responder socket and the  
ability to send a crafted `SSS_PAM_AUTHENTICATE` request with `authtok`  
type `SSS_AUTHTOK_TYPE_PASSKEY_KRB`, a non-NULL passkey `prompt` and `key`,  
and no prior successful `SSS_PAM_PREAUTH` that would initialize  
`pk_table_data`. The affected path is present only when the package is  
built with `BUILD_PASSKEY` and `pam_passkey_auth` 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/pamsrv_passkey.c` (`passkey_kerberos()`), with  
reachability from `src/responder/pam/pamsrv_cmd.c` and state initialization  
in `save_passkey_data()`.
Version affected: `sssd-2.12.0-1.el10`, when built with passkey support  
(`BUILD_PASSKEY`) and with `pam_passkey_auth = 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  
`SSS_AUTHTOK_TYPE_PASSKEY_KRB` 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 `sssd_pam` 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: `passkey_kerberos()` validates that the  
attacker-controlled passkey blob contains non-NULL `prompt` and `key`  
fields, but it does not verify that `pctx->pk_table_data` exists before  
dereferencing `pctx->pk_table_data->table`:
```c
if (prompt == NULL || key == NULL) {
DEBUG(SSSDBG_OP_FAILURE,
"Passkey prompt and key are missing or invalid.\n");
return EIO;
}
data = sss_ptr_hash_lookup(pctx->pk_table_data->table, key,
struct pk_child_user_data);
if (data == NULL) {
DEBUG(SSSDBG_OP_FAILURE,
"Failed to lookup passkey authtok\n");
return EIO;
}
```
That state is allocated in `save_passkey_data()`, which is reached from  
passkey pre-auth response handling:
```c
pctx->pk_table_data = talloc_zero(tmp_ctx, struct  
pam_passkey_table_data);
if (pctx->pk_table_data == NULL) {
return ENOMEM;
}
if (pctx->pk_table_data->table == NULL) {
pctx->pk_table_data->table =  
sss_ptr_hash_create(pctx->pk_table_data,
NULL, NULL);
if (pctx->pk_table_data->table == NULL) {
ret = ENOMEM;
goto done;
}
}
```
The authenticate path can still dispatch to `passkey_kerberos()` based on  
token type alone:
```c
#ifdef BUILD_PASSKEY
if ((pd->cmd == SSS_PAM_AUTHENTICATE)) {
if (may_do_passkey_auth(pctx, pd)) {
if (sss_authtok_get_type(pd->authtok) ==  
SSS_AUTHTOK_TYPE_PASSKEY_KRB) {
ret = passkey_kerberos(pctx, preq->pd, preq);
goto done;
} else if ((sss_authtok_get_type(pd->authtok) ==  
SSS_AUTHTOK_TYPE_PASSKEY) ||
(sss_authtok_get_type(pd->authtok) ==  
SSS_AUTHTOK_TYPE_EMPTY)) {
ret = passkey_local(cctx, cctx->ev, pctx, preq, pd);
```
The request parser also accepts `SSS_AUTHTOK_TYPE_PASSKEY_KRB` directly  
from client input:
```c
case SSS_AUTHTOK_TYPE_PASSKEY:
case SSS_AUTHTOK_TYPE_PASSKEY_KRB:
case SSS_AUTHTOK_TYPE_PASSKEY_REPLY:
case SSS_AUTHTOK_TYPE_PAM_STACKED:
ret = sss_authtok_set(tok, auth_token_type,
auth_token_data, auth_token_length);
break;
```
As a result, a crafted local `SSS_PAM_AUTHENTICATE` request can select the  
passkey-Kerberos path without first populating `pk_table_data`. When that  
happens, the dereference of `pctx->pk_table_data->table` triggers a NULL  
pointer dereference and crashes `sssd_pam`. The available evidence supports  
availability impact only.
Steps to reproduce:
1. Use a build with passkey support enabled (`BUILD_PASSKEY`) and with  
`pam_passkey_auth = true`.
2. Connect to the PAM responder UNIX socket (`.../pipes/pam`).
3. Send a protocol v3 `SSS_PAM_AUTHENTICATE` request with `authtok` type  
`SSS_AUTHTOK_TYPE_PASSKEY_KRB`, a passkey blob containing non-NULL `prompt`  
and `key` fields, and no prior successful `SSS_PAM_PREAUTH` that would  
populate `pk_table_data`.
4. Observe `sssd_pam` crash from the NULL dereference at  
`pctx->pk_table_data->table` in `passkey_kerberos()`.
Mitigation: If passkey authentication is not required, disable  
`pam_passkey_auth` 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->pk_table_data->table`  
and return an error when passkey Kerberos state has not been initialized.
```diff
diff --git a/src/responder/pam/pamsrv_passkey.c  
b/src/responder/pam/pamsrv_passkey.c
— a/src/responder/pam/pamsrv_passkey.c
+++ b/src/responder/pam/pamsrv_passkey.c
@@ -144,6 +144,13 @@ errno_t passkey_kerberos(struct pam_ctx *pctx,
return EIO;
}
+    if (pctx->pk_table_data == NULL || pctx->pk_table_data->table == NULL)  
{
+        DEBUG(SSSDBG_OP_FAILURE,
+              "Passkey KRB state table missing (pre-auth state not  
initialized).\n");
+        return EIO;
+    }
+
data = sss_ptr_hash_lookup(pctx->pk_table_data->table, key,
struct pk_child_user_data);
if (data == NULL) {
```
------
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.