AI_ONLY_REPORT
package: sssd-2.12.0-1.el10
------
Summary: Local DoS in PAM GSSAPI flow via stale `cli_ctx->state_ctx`  
pointer (UAF pattern): a successful GSSAPI context completion frees cached  
per-connection state without clearing the connection pointer, so a later  
same-socket `SSS_GSSAPI_SEC_CTX` request can terminate the PAM responder  
and disrupt authentication availability.
Requirements to exploit: Local access to a system running the affected  
package, PAM GSSAPI enabled for at least one service, and the ability to  
drive a GSSAPI exchange to successful context establishment and then send  
another `SSS_GSSAPI_SEC_CTX` request on the same responder connection.
Component affected: `sssd-2.12.0-1.el10`,  
`src/responder/pam/pamsrv_gssapi.c`, `gssapi_get_state()`,  
`pam_cmd_gssapi_sec_ctx_done()`
Version affected: `sssd-2.12.0-1.el10` when the PAM responder GSSAPI flow  
is enabled for at least one service
Patch available: no released package fix established; proposed patch  
included below
Version fixed: unknown
Upstream coordination: Not notified.
CVSS: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H - 4.9 (MEDIUM)
AV:L - Exploitation requires local access to the PAM responder  
socket/protocol.
AC:H - The vulnerable path depends on PAM GSSAPI being enabled and on  
reaching successful context establishment on the same connection before  
sending another `SSS_GSSAPI_SEC_CTX` request.
PR:L - The described attack model requires a low-privileged local  
account.
UI:N - No separate victim interaction is required once the attacker can  
issue the protocol requests.
S:U - The impact is limited to the PAM responder's security scope.
C:N - No confidentiality impact is established by the available evidence.
I:N - No integrity impact is established by the available evidence.
A:H - A successful trigger can terminate the responder and deny PAM  
authentication service until it is restarted.
Impact: Moderate. This issue can cause a meaningful availability failure  
for PAM authentication in affected deployments, but it is local,  
configuration-dependent, and tied to the successful GSSAPI completion path  
on the same connection. Under Red Hat's guidance, that is more consistent  
with Moderate than Important because it is not an easy remote DoS and does  
not demonstrate confidentiality or integrity compromise.
Embargo: no
Reason: The issue is local, setup-dependent, and availability-only,  
with straightforward operational mitigation and no demonstrated  
confidentiality or integrity impact.
Acknowledgement: Aisle Research
Vulnerability Details: The PAM responder caches per-connection GSSAPI state  
in `cli_ctx->state_ctx` and reuses it on later requests:
```c
static struct gssapi_state *gssapi_get_state(struct cli_ctx *cli_ctx,
const char *username,
struct sss_domain_info *domain)
{
struct gssapi_state *state;
state = talloc_get_type(cli_ctx->state_ctx, struct gssapi_state);
if (state != NULL) {
return state;
}
...
cli_ctx->state_ctx = state;
return state;
}
```
That cached state is later freed on the callback completion path:
```c
static void pam_cmd_gssapi_sec_ctx_done(struct tevent_req *req)
{
...
done:
DEBUG(SSSDBG_TRACE_FUNC, "Returning [%d]: %s\n", ret,  
sss_strerror(ret));
if (ret == EOK) {
sss_packet_set_error(pctx->creq->out, EOK);
} else {
sss_cmd_send_error(state->cli_ctx, ret);
}
sss_cmd_done(state->cli_ctx, state);
}
```
Based on the available code, `sss_cmd_done(state->cli_ctx, state)` frees  
`state` but does not clear `cli_ctx->state_ctx`, leaving a stale  
per-connection pointer behind. A subsequent `SSS_GSSAPI_SEC_CTX` request on  
the same socket re-enters `gssapi_get_state()` and consults  
`cli_ctx->state_ctx` again. In builds where `talloc` detects the freed  
chunk as invalid, this can abort the responder and cause a local denial of  
service against PAM authentication.
The synchronous error path in `pam_cmd_gssapi_sec_ctx()` ends with  
`sss_cmd_done(cli_ctx, NULL)` and, based on the available code, does not  
appear to be the vulnerable free. The stale-pointer condition appears tied  
to the successful callback completion path.
Steps to reproduce:
1. Configure PAM GSSAPI for at least one service, for example by including  
a test service in `pam_gssapi_services`.
2. Connect as a local user to the PAM responder socket and issue  
`SSS_GSSAPI_INIT`.
3. Send `SSS_GSSAPI_SEC_CTX` tokens until context establishment succeeds  
and the callback completion path is reached.
4. Keep the same socket open and send one additional `SSS_GSSAPI_SEC_CTX`  
request.
5. Observe responder crash or abort behavior consistent with stale  
`cli_ctx->state_ctx` reuse in `gssapi_get_state()`.
Mitigation: If an immediate code fix is not possible, disable PAM GSSAPI  
for affected services or otherwise prevent use of the PAM responder's  
GSSAPI flow. Restarting the PAM responder can restore service after a  
crash, but it does not remove the underlying bug.
Proposed Fix: Clear `cli_ctx->state_ctx` before freeing `state` in  
`pam_cmd_gssapi_sec_ctx_done()`.
```diff
diff --git a/src/responder/pam/pamsrv_gssapi.c  
b/src/responder/pam/pamsrv_gssapi.c
— a/src/responder/pam/pamsrv_gssapi.c
+++ b/src/responder/pam/pamsrv_gssapi.c
@@ -1060,6 +1060,10 @@ static void pam_cmd_gssapi_sec_ctx_done(struct  
tevent_req *req)
sss_cmd_send_error(state->cli_ctx, ret);
}
+    if (state->cli_ctx->state_ctx == state) {
+        state->cli_ctx->state_ctx = NULL;
+    }
+
sss_cmd_done(state->cli_ctx, state);
}
```
Equivalent hardening in `gssapi_state_destructor()` is also reasonable.
------
This report was generated using AI technology. Always review AI-generated  
content prior to use