Bug 2569236

Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process.

AI_ONLY_REPORT
package: krb5-1.21.3-8.el10_0
------
Summary: Authenticated DoS via Memory Leak in `xdr_krb5_tl_data` Decode  
Error Path: malformed authenticated `kadmind` RPC requests with non-null  
`tl_data` can leak heap allocations on decode failure and eventually  
exhaust process memory.
Requirements to exploit: Network reachability to `kadmind`, valid  
credentials for a principal able to establish an authenticated RPCSEC_GSS  
session to the kadmin RPC service, and the ability to send a malformed  
request that decodes `kadm5_principal_ent_rec` with non-null `tl_data`.
Component affected: `krb5-1.21.3-8.el10_0`, `src/lib/kadm5/kadm_rpc_xdr.c`,  
`xdr_krb5_tl_data()` in the `kadmind` request decode path for  
`kadm5_principal_ent_rec.tl_data`.
Version affected: `krb5-1.21.3-8.el10_0`
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:L/UI:N/S:U/C:N/I:N/A:H - 6.5 (MEDIUM)
AV:N - The vulnerable path is reachable over the network through the  
`kadmind` RPC service.
AC:L - Exploitation only requires sending malformed `tl_data` that fails  
decoding after allocation.
PR:L - A valid authenticated RPCSEC_GSS session to `kadmind` is  
required; the leak occurs during request decoding rather than after  
successful completion of the requested administrative operation.
UI:N - No user interaction is required once the attacker can send  
requests.
S:U - The impact is confined to the `kadmind` service boundary.
C:N - No confidentiality impact is established by the available evidence.
I:N - No integrity impact is established by the available evidence.
A:H - Repeated requests can drive unbounded memory growth and deny  
availability of the long-lived `kadmind` process.
Impact: Important. Red Hat classifies remote denial of service issues as  
Important when they can readily compromise service availability. This issue  
allows an authenticated remote user to repeatedly exhaust memory in  
`kadmind` through a normal request decode path once a valid session exists.  
Critical is not appropriate because authentication is required and no code  
execution, privilege escalation, or broader system compromise is  
established.
Embargo: no
Reason: The issue is limited to authenticated availability impact  
against an administrative service, and operators can reduce exposure by  
restricting access to `kadmind` until a fix is available.
Acknowledgement: Aisle Research
Vulnerability Details: In `xdr_krb5_tl_data()`, the `XDR_DECODE` path  
allocates a new `krb5_tl_data` element and decodes its fields before the  
accumulated list is linked into `*tl_data_head`. The affected block is:
```c
case XDR_DECODE:
tl = NULL;
while (1) {
if (!xdr_bool(xdrs, &more))
return FALSE;
if (more == FALSE)
break;
tl2 = (krb5_tl_data *) malloc(sizeof(krb5_tl_data));
if (tl2 == NULL)
return FALSE;
memset(tl2, 0, sizeof(krb5_tl_data));
if (!xdr_krb5_int16(xdrs, &tl2->tl_data_type))
return FALSE;
if (!xdr_bytes(xdrs, (char **)&tl2->tl_data_contents, &len, ~0))
return FALSE;
tl2->tl_data_length = len;
tl2->tl_data_next = tl;
tl = tl2;
}
*tl_data_head = tl;
break;
```
If `xdr_bool`, `xdr_krb5_int16`, or `xdr_bytes` fails after allocation, the  
function returns `FALSE` immediately. At that point, the current `tl2`  
allocation, any `tl2->tl_data_contents` buffer allocated by `xdr_bytes`,  
and any previously built `tl` chain are not attached to `*tl_data_head`. In  
the `kadmind` request path, failed RPC argument decoding is cleaned up  
through the decoded argument object; because the partially constructed list  
is never linked into that object, those allocations remain unreachable to  
normal `XDR_FREE` cleanup and are leaked. The available evidence shows this  
is reachable with authenticated `CREATE_PRINCIPAL` and `MODIFY_PRINCIPAL`  
requests that carry non-null `rec.tl_data`.
Steps to reproduce:
1. Start `kadmind` built from `krb5-1.21.3-8.el10_0` with normal RPCSEC_GSS  
authentication.
2. Authenticate as any principal able to establish a valid RPCSEC_GSS  
session to the kadmin RPC service.
3. Send a `CREATE_PRINCIPAL` or `MODIFY_PRINCIPAL` RPC request containing  
non-null `rec.tl_data`.
4. In the `tl_data` sequence, set `more = TRUE`, begin one entry, then  
truncate or corrupt the stream so decoding fails at `xdr_krb5_int16` or  
`xdr_bytes`.
5. Repeat the malformed request and monitor `kadmind` RSS with `ps` or  
`/proc/<pid>/status`; the process memory grows monotonically across failed  
decodes.
Mitigation: Until a fixed package is available, restrict network access to  
`kadmind` to trusted administration hosts, limit which principals can  
establish authenticated sessions where deployment policy allows, and  
monitor or restart `kadmind` if abnormal RSS growth is observed. Disabling  
`kadmind` where it is not required removes remote exposure to the  
vulnerable decode path.
Proposed Fix: Route all `XDR_DECODE` failures through a cleanup path that  
frees the current element and any previously built `tl_data` chain before  
returning `FALSE`.
```diff
diff --git a/src/lib/kadm5/kadm_rpc_xdr.c b/src/lib/kadm5/kadm_rpc_xdr.c
— a/src/lib/kadm5/kadm_rpc_xdr.c
+++ b/src/lib/kadm5/kadm_rpc_xdr.c
@@ -334,27 +334,40 @@ bool_t xdr_krb5_tl_data(XDR *xdrs, krb5_tl_data  
**tl_data_head)
case XDR_DECODE:
         tl = NULL;
+          tl = NULL;
            while (1) {
                 if (!xdr_bool(xdrs, &more))

                   return FALSE;
+                    goto decode_fail;
                 if (more == FALSE)
                      break;
                 tl2 = (krb5_tl_data *) malloc(sizeof(krb5_tl_data));
                 if (tl2 == NULL)

                   return FALSE;
+                    goto decode_fail;
                 memset(tl2, 0, sizeof(krb5_tl_data));

              if (!xdr_krb5_int16(xdrs, &tl2->tl_data_type))

                   return FALSE;

              if (!xdr_bytes(xdrs, (char **)&tl2->tl_data_contents, &len,  
~0))

                   return FALSE;
+               if (!xdr_krb5_int16(xdrs, &tl2->tl_data_type)) {
+                    free(tl2);
+                    goto decode_fail;
+               }
+               if (!xdr_bytes(xdrs, (char **)&tl2->tl_data_contents, &len,  
~0)) {
+                    free(tl2->tl_data_contents);
+                    free(tl2);
+                    goto decode_fail;
+               }
                 tl2->tl_data_length = len;


tl2->tl_data_next = tl;
tl = tl2;
}
*tl_data_head = tl;
break;
+
+decode_fail:
+          while (tl != NULL) {
+               tl2 = tl->tl_data_next;
+               free(tl->tl_data_contents);
+               free(tl);
+               tl = tl2;
+          }
+          return FALSE;
}
```
------
This report was generated using AI technology. Always review AI-generated  
content prior to use