CVE-2026-112317: Krb5: mit krb5 kdc unauthenticated memory leak dos in kdb keytab key decryption error path

AIONLYREPORT package: krb5-1.21.3-8.el100 ------ Summary: KDB keytab memory leak in krb5ktkdbgetentry() error paths (remote DoS): decrypted key material is left allocated when krb5ktkdbgetentry() takes a later error path, allowing repeated remote requests against exposed KDB:-backed service paths to accumulate leaked memory and degrade availability. Requirements to exploit: Network reachability to a deployment of krb5-1.21.3-8.el100 that exposes a service path using the KDB: keytab, the ability to send repeated crafted requests that make krb5ktkdbgetentry() fail after krb5dbedecryptkeydata() succeeds, and enough request volume to accumulate leaked heap memory. Based on the observed request flow, prior authentication is not required to reach the lookup path. Component affected: krb5-1.21.3-8.el100, src/lib/kdb/keytab.c, krb5ktkdbgetentry(); reachable through KDB:-backed administrative/password-change request handling. Version affected: krb5-1.21.3-8.el100 in builds that include the non-LEANCLIENT KDB: keytab code and expose a network-facing service path using KDB: Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Not notified. CVSS: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L - 5.3 (MEDIUM) AV:N - The affected lookup path can be reached over the network through exposed KDB:-backed administrative/password-change services. AC:L - No race or special attack condition is established beyond reaching the affected service and causing a post-decrypt error. PR:N - The request reaches keytab lookup before the client is authenticated. UI:N - No user interaction is required. S:U - The impact is limited to the affected service process. C:N - No confidentiality impact is established. I:N - No integrity impact is established. A:L - Repeated requests can leak memory and degrade or eventually interrupt service availability, but the established effect is incremental resource exhaustion. Impact: Important. Red Hat classifies flaws that allow remote users to cause a denial of service as Important. Here, the established impact is remote availability loss against an exposed network service path without prior authentication. This is not Critical because no code execution, confidentiality loss, or broader system compromise is established. The issue is deployment-dependent on use of KDB:-backed service paths, but where those paths are exposed it fits the Important category more closely than Moderate. Embargo: no Reason: The established impact is availability degradation rather than code execution or data compromise, and exposure can be reduced operationally by restricting access to the affected services while a fix is prepared. Acknowledgement: Aisle Research Vulnerability Details: In src/lib/kdb/keytab.c, krb5ktkdbgetentry() decrypts the selected KDB key into entry->key. If a later check fails, execution jumps to error: and returns without releasing that key material: c kerror = krb5dbedecryptkeydata(context, NULL, keydata, &entry->key, NULL); if (kerror) goto error; if (enctype > 0) { kerror = krb5cenctypecompare(context, enctype, entry->key.enctype, &similar); if (kerror) goto error; if (!similar) { kerror = KRB5KDBNOPERMITTEDKEY; goto error; } } / Coerce the enctype of the output keyblock in case we got an

inexact match on the enctype. / entry->key.enctype = enctype;

kerror = krb5copyprincipal(context, principal, &entry->principal); if (kerror) goto error; / Close database / error: krb5dbfreeprincipal(context, dbentry); / krb5dbclosedatabase(context); / return(kerror); The most straightforward post-decrypt failure shown by the code is a non-similar enctype comparison leading to KRB5KDBNOPERMITTEDKEY; an allocation failure in krb5copyprincipal() would have the same leak outcome. The generic keytab dispatch path returns provider errors without reclaiming partially initialized entry state, so once this function returns an error after populating entry->key, the allocation becomes unreachable. A concrete network-facing use of this path exists where the administrative/password-change service resolves KDB: and authenticates incoming requests against it. Based on the available technical evidence, the remote availability impact is well supported for deployments exposing those KDB:-backed service paths. This report does not rely on a broader claim that every Kerberos service path in the package is affected in the same way. Steps to reproduce: 1. Deploy krb5-1.21.3-8.el100 with its database initialized and a network-reachable administrative or password-change service path that uses KDB:. 2. Send repeated AP-REQ requests to that service so it performs krb5ktgetentry() and then krb5ktkdbgetentry() for the service principal. 3. Craft requests so lookup reaches a post-decrypt error after krb5dbedecryptkeydata() succeeds. A non-similar enctype causing KRB5KDBNOPERMITTEDKEY is one concrete condition visible in the code. 4. Observe the daemon's memory usage over many failing requests. Resident memory should grow while the requests continue to fail. 5. Apply the patch below, rebuild, and repeat the same request pattern. Memory growth from this error path should no longer accumulate. Mitigation: Until a fix is shipped, restrict network access to the administrative/password-change interfaces that use KDB:, disable those services if they are not required, and apply rate limiting or ACLs to untrusted sources. If repeated failures have already caused memory growth, restarting the affected daemon recovers the leaked heap state. Proposed Fix: Track whether entry->key has been populated and free it on error before returning. diff diff --git a/src/lib/kdb/keytab.c b/src/lib/kdb/keytab.c — a/src/lib/kdb/keytab.c +++ b/src/lib/kdb/keytab.c @@ -123,6 +123,7 @@ krb5ktkdbgetentry(krb5context incontext, krb5keytab id, krb5keydata keydata; krb5dbentry dbentry; int xrealmtgt; + krb5boolean keypopulated = FALSE; krb5boolean similar; @@ -166,8 +167,10 @@ krb5ktkdbgetentry(krb5context incontext, krb5keytab id, kerror = krb5dbedecryptkeydata(context, NULL, keydata, &entry->key, NULL); if (kerror) goto error; + keypopulated = TRUE; @@ -193,6 +196,8 @@ krb5ktkdbgetentry(krb5context incontext, krb5keytab id, error: + if (kerror && keypopulated) + krb5freekeyblockcontents(context, &entry->key); krb5dbfreeprincipal(context, dbentry); / krb5dbclosedatabase(context); / return(kerror); ------ This report was generated using AI technology. Always review AI-generated content prior to use