Bug 2478448 (CVE-2026-112321) - CVE-2026-112321 krb5: MIT krb5 kadmind unauthenticated memory leak DoS via AUTH_GSSAPI_INIT error paths
Summary: CVE-2026-112321 krb5: MIT krb5 kadmind unauthenticated memory leak DoS via AU...
Keywords:
Status: NEW
Alias: CVE-2026-112321
Deadline: 2026-11-09
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On: 2569229
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-05-18 03:35 UTC by OSIDB Bzimport
Modified: 2026-11-09 18:12 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-05-18 03:35:10 UTC
AI_ONLY_REPORT
package: krb5-1.21.3-8.el10_0
------
Summary: Pre-auth memory leak in legacy AUTH_GSSAPI INIT path  
(`svc_auth_gssapi.c`) enables remote DoS: crafted `AUTH_GSSAPI_INIT`  
requests can leak decoded token memory on early error exits and exhaust an  
affected network service that accepts legacy `AUTH_GSSAPI`.
Requirements to exploit: The attacker needs network access to a service  
built from `krb5-1.21.3-8.el10_0` that accepts legacy `AUTH_GSSAPI` and  
processes `AUTH_GSSAPI_INIT` before authentication. No valid credentials,  
completed GSS context, or user interaction are required, but the request  
must be syntactically valid enough for `svc_getargs()` to decode  
`call_arg`; larger token payloads increase the leak rate within the request  
sizes the exposed service accepts.
Component affected: `krb5-1.21.3-8.el10_0`, legacy `AUTH_GSSAPI`  
server-side INIT handling in `src/lib/rpc/svc_auth_gssapi.c`, function  
`gssrpc__svcauth_gssapi()`
Version affected: `krb5-1.21.3-8.el10_0` when deployed with a service that  
accepts legacy `AUTH_GSSAPI` requests
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:H - 7.5 (HIGH)
AV:N - The issue is reachable over network RPC in services that expose  
the vulnerable legacy `AUTH_GSSAPI` path.
AC:L - Once that path is exposed, sending a decodable `AUTH_GSSAPI_INIT`  
request with an unsupported version is straightforward.
PR:N - The leak occurs before authentication completes and does not  
require valid credentials.
UI:N - No user interaction is needed.
S:U - The impact is contained to the vulnerable service.
C:N - No confidentiality impact is demonstrated.
I:N - No integrity impact is demonstrated.
A:H - Repeated requests can accumulate leaked memory and deny service  
through memory exhaustion.
Impact: Important. Red Hat guidance classifies flaws that allow remote  
users to cause a denial of service as Important, and this issue permits  
unauthenticated remote memory exhaustion against an affected network  
service. The legacy nature of the `AUTH_GSSAPI` path narrows exposure, but  
the demonstrated consequence is still a direct remote availability loss  
rather than a merely theoretical source-only defect.
Embargo: no
Reason: This is an availability-only flaw in a legacy authentication  
path, the fix is small and low risk, and operators can reduce exposure by  
restricting access to affected services while a package update is prepared.
Acknowledgement: Aisle Research
Vulnerability Details: During pre-auth `AUTH_GSSAPI_INIT` handling,  
`gssrpc__svcauth_gssapi()` decodes attacker-controlled input into  
`call_arg`. Two subsequent error branches return through `error:` before  
the only INIT-path `xdr_free((xdrproc_t)xdr_authgssapi_init_arg,  
&call_arg);` is reached, and the shared `error:` block frees only `creds`.  
As a result, the decoded token buffer can be leaked once per request.
```c
/* call is for us, deserialize arguments */
memset(&call_arg, 0, sizeof(call_arg));
if (! svc_getargs(rqst->rq_xprt, (xdrproc_t)xdr_authgssapi_init_arg,
&call_arg)) {
PRINTF(("svcauth_gssapi: cannot decode args\n"));
LOG_MISCERR("protocol error in procedure arguments");
ret = AUTH_BADCRED;
goto error;
}
...
switch (call_arg.version) {
...
default:
PRINTF(("svcauth_gssapi: bad GSSAPI_INIT version\n"));
LOG_MISCERR("unsupported GSSAPI_INIT version");
ret = AUTH_BADCRED;
goto error;
}
...
if (rqst->rq_xprt->xp_laddrlen > 0) {
bindings.acceptor_addrtype = GSS_C_AF_INET;
bindings.acceptor_address.length = 4;
bindings.acceptor_address.value =
&rqst->rq_xprt->xp_laddr.sin_addr.s_addr;
} else {
LOG_MISCERR("cannot get local address");
ret = AUTH_FAILED;
goto error;
}
...
/* done with call args */
xdr_free((xdrproc_t)xdr_authgssapi_init_arg, &call_arg);
...
error:
if (creds.client_handle.length != 0) {
PRINTF(("svcauth_gssapi: freeing client_handle len %d\n",
(int) creds.client_handle.length));
xdr_free((xdrproc_t)xdr_authgssapi_creds, &creds);
}
PRINTF(("\n"));
return ret;
```
The unsupported-version branch is sufficient to trigger the leak and does  
not depend on the less common `xp_laddrlen <= 0` case. The available  
package context also shows server-side acceptance of `AUTH_GSSAPI` in  
`kadmind`, so this is not limited to unreachable library code. Transport  
cleanup does not resolve this case because the relevant cleanup happens  
only on decode failure, not on later application-auth error exits after  
`call_arg` has already been allocated.
Steps to reproduce:
1. Run a service from `krb5-1.21.3-8.el10_0` that accepts legacy  
`AUTH_GSSAPI` requests, such as `kadmind`, with ASAN or RSS monitoring  
enabled.
2. Send RPC requests with auth flavor `AUTH_GSSAPI`, procedure  
`AUTH_GSSAPI_INIT`, and wrapper fields that allow `svc_getargs(...,  
xdr_authgssapi_init_arg, &call_arg)` to decode successfully, such as  
`creds.version=2`, `auth_msg=true`, and an empty `client_handle`.
3. Set `call_arg.version` to an unsupported value such as `5`, and include  
a large `token` so the decoded `call_arg.token` allocation is substantial.
4. Repeat the request and observe monotonic memory growth without a  
corresponding free for the decoded INIT token.
5. Confirm the request exits through the unsupported-version branch, or the  
`xp_laddrlen <= 0` branch, before reaching the sole INIT-path  
`xdr_free((xdrproc_t)xdr_authgssapi_init_arg, &call_arg);`.
Mitigation: Until a fixed package is available, restrict network access to  
services that accept legacy `AUTH_GSSAPI` to trusted management networks  
and monitor or rate-limit repeated failing `AUTH_GSSAPI_INIT` traffic where  
possible. If operationally feasible, prefer deployments that do not expose  
the legacy `AUTH_GSSAPI` path to untrusted clients.
Proposed Fix: Free `call_arg` before each early `goto error` that occurs  
after successful INIT decode.
```diff
diff --git a/src/lib/rpc/svc_auth_gssapi.c b/src/lib/rpc/svc_auth_gssapi.c
— a/src/lib/rpc/svc_auth_gssapi.c
+++ b/src/lib/rpc/svc_auth_gssapi.c
@@ -337,6 +337,7 @@
default:
PRINTF(("svcauth_gssapi: bad GSSAPI_INIT version\n"));
LOG_MISCERR("unsupported GSSAPI_INIT version");
+           xdr_free((xdrproc_t)xdr_authgssapi_init_arg, &call_arg);
ret = AUTH_BADCRED;
goto error;
}
@@ -361,6 +362,7 @@
} else {
LOG_MISCERR("cannot get local address");
+           xdr_free((xdrproc_t)xdr_authgssapi_init_arg, &call_arg);
ret = AUTH_FAILED;
goto error;
}
```
------
This report was generated using AI technology. Always review AI-generated  
content prior to use

Comment 1 Christopher Lusk 2026-06-26 17:07:38 UTC
Tracker filed for rhel-10.3: https://issues.redhat.com/browse/RHEL-189008


Note You need to log in before you can comment on or make changes to this bug.