Bug 2479178 (CVE-2026-104034) - CVE-2026-104034 sssd: SSSD: Denial of Service via use-after-free in KCM ticket renewal
Summary: CVE-2026-104034 sssd: SSSD: Denial of Service via use-after-free in KCM ticke...
Keywords:
Status: NEW
Alias: CVE-2026-104034
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: 2546219
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-05-18 03:57 UTC by OSIDB Bzimport
Modified: 2026-10-05 23:30 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:57:55 UTC
AI_ONLY_REPORT
package: sssd-2.12.0-1.el10
------
Summary: Use-After-Free in KCM TGT Renewal (`auth_data->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 `tgt_renewal = true`; the user then waits for the normal renewal  
window.
Component affected: `sssd-2.12.0-1.el10`, `src/responder/kcm/kcm_renew.c`,  
KCM TGT renewal path in `kcm_creds_check_times()` with deferred use in  
`kcm_renew_tgt()` / `kcm_child_req_setup()`.
Version affected: `sssd-2.12.0-1.el10`; reachability depends on builds with  
KCM renewal support and deployments using the KCM `secdb` backend with  
`tgt_renewal = 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 `tgt_renewal` 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
auth_data->ccname = cc->name;
...
talloc_free(tmp_ctx);
...
krreq->ccname = talloc_asprintf(krreq, "KCM:%s", auth_data->ccname);
```
`auth_data` 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 `tmp_ctx`, which is freed after  
renewal scheduling completes. When the deferred path reaches  
`kcm_child_req_setup()`, `auth_data->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 `tgt_renewal =  
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 `kcm_renew_tgt`, then allow the timer  
handler to finish and free `tmp_ctx`.
7. Run under ASan or Valgrind and observe an invalid read or use-after-free  
report when `kcm_child_req_setup()` formats `KCM:%s` with  
`auth_data->ccname`.
Mitigation: If KCM ticket renewal is not required, keep `tgt_renewal =  
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 `auth_data` before scheduling the  
deferred callback, and fail cleanly if that allocation cannot be made.
```diff
diff --git a/src/responder/kcm/kcm_renew.c b/src/responder/kcm/kcm_renew.c
@@ -579,11 +579,16 @@ static errno_t kcm_creds_check_times(TALLOC_CTX  
*mem_ctx,
auth_data->krb5_ctx = renew_tgt_ctx->krb5_ctx;
auth_data->upn = talloc_strdup(auth_data, client_name);
auth_data->uid = cc->owner.uid;
auth_data->gid = cc->owner.gid;
           auth_data->ccname = cc->name;
+            auth_data->ccname = talloc_strdup(auth_data, cc->name);
              if (auth_data->upn == NULL) {
                  ret = ENOMEM;
                  DEBUG(SSSDBG_CRIT_FAILURE, "Unable to allocate  
auth_data->upn for renewals\n");
                  goto done;
              }
+            if (auth_data->ccname == NULL) {
+                ret = ENOMEM;
+                DEBUG(SSSDBG_CRIT_FAILURE, "Unable to allocate  
auth_data->ccname for renewals\n");
+                goto done;
+            }
```


------
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.