Bug 2479209 (CVE-2026-112317)

AI_ONLY_REPORT
package: krb5-1.21.3-8.el10_0
------
Summary: KDB keytab memory leak in `krb5_ktkdb_get_entry()` error paths  
(remote DoS): decrypted key material is left allocated when  
`krb5_ktkdb_get_entry()` 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.el10_0` that exposes a service path using the `KDB:` keytab,  
the ability to send repeated crafted requests that make  
`krb5_ktkdb_get_entry()` fail after `krb5_dbe_decrypt_key_data()` 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.el10_0`, `src/lib/kdb/keytab.c`,  
`krb5_ktkdb_get_entry()`; reachable through `KDB:`-backed  
administrative/password-change request handling.
Version affected: `krb5-1.21.3-8.el10_0` in builds that include the  
non-`LEAN_CLIENT` `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`, `krb5_ktkdb_get_entry()`  
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 = krb5_dbe_decrypt_key_data(context, NULL, key_data,
&entry->key, NULL);
if (kerror)
goto error;
if (enctype > 0) {
kerror = krb5_c_enctype_compare(context, enctype,
entry->key.enctype, &similar);
if (kerror)
goto error;
if (!similar) {
kerror = KRB5_KDB_NO_PERMITTED_KEY;
goto error;
}
}
/*
Coerce the enctype of the output keyblock in case we got an

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


kerror = krb5_copy_principal(context, principal, &entry->principal);
if (kerror)
goto error;
/* Close database */
error:
krb5_db_free_principal(context, db_entry);
/*    krb5_db_close_database(context); */
return(kerror);
```
The most straightforward post-decrypt failure shown by the code is a  
non-similar enctype comparison leading to `KRB5_KDB_NO_PERMITTED_KEY`; an  
allocation failure in `krb5_copy_principal()` 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.el10_0` 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  
`krb5_kt_get_entry()` and then `krb5_ktkdb_get_entry()` for the service  
principal.
3. Craft requests so lookup reaches a post-decrypt error after  
`krb5_dbe_decrypt_key_data()` succeeds. A non-similar enctype causing  
`KRB5_KDB_NO_PERMITTED_KEY` 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 @@ krb5_ktkdb_get_entry(krb5_context in_context,  
krb5_keytab id,
krb5_key_data       * key_data;
krb5_db_entry       * db_entry;
int xrealm_tgt;
+    krb5_boolean key_populated = FALSE;
krb5_boolean similar;
@@ -166,8 +167,10 @@ krb5_ktkdb_get_entry(krb5_context in_context,  
krb5_keytab id,
kerror = krb5_dbe_decrypt_key_data(context, NULL, key_data,
&entry->key, NULL);
if (kerror)
goto error;
+    key_populated = TRUE;
@@ -193,6 +196,8 @@ krb5_ktkdb_get_entry(krb5_context in_context,  
krb5_keytab id,
error:
+    if (kerror && key_populated)
+        krb5_free_keyblock_contents(context, &entry->key);
krb5_db_free_principal(context, db_entry);
/*    krb5_db_close_database(context); */
return(kerror);
```
------
This report was generated using AI technology. Always review AI-generated  
content prior to use