CVE-2026-112321: Krb5: mit krb5 kadmind unauthenticated memory leak dos via auth_gssapi_init error paths

Published May 18, 2026
·
Updated

AIONLYREPORT package: krb5-1.21.3-8.el100 ------ Summary: Pre-auth memory leak in legacy AUTHGSSAPI INIT path (svcauthgssapi.c) enables remote DoS: crafted AUTHGSSAPIINIT requests can leak decoded token memory on early error exits and exhaust an affected network service that accepts legacy AUTHGSSAPI. Requirements to exploit: The attacker needs network access to a service built from krb5-1.21.3-8.el100 that accepts legacy AUTHGSSAPI and processes AUTHGSSAPIINIT before authentication. No valid credentials, completed GSS context, or user interaction are required, but the request must be syntactically valid enough for svcgetargs() to decode callarg; larger token payloads increase the leak rate within the request sizes the exposed service accepts. Component affected: krb5-1.21.3-8.el100, legacy AUTHGSSAPI server-side INIT handling in src/lib/rpc/svcauthgssapi.c, function gssrpcsvcauthgssapi() Version affected: krb5-1.21.3-8.el100 when deployed with a service that accepts legacy AUTHGSSAPI 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 AUTHGSSAPI path. AC:L - Once that path is exposed, sending a decodable AUTHGSSAPIINIT 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 AUTHGSSAPI 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 AUTHGSSAPIINIT handling, gssrpcsvcauthgssapi() decodes attacker-controlled input into callarg. Two subsequent error branches return through error: before the only INIT-path xdrfree((xdrproct)xdrauthgssapiinitarg, &callarg); 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(&callarg, 0, sizeof(callarg)); if (! svcgetargs(rqst->rqxprt, (xdrproct)xdrauthgssapiinitarg, &callarg)) { PRINTF(("svcauthgssapi: cannot decode args\n")); LOGMISCERR("protocol error in procedure arguments"); ret = AUTHBADCRED; goto error; } ... switch (callarg.version) { ... default: PRINTF(("svcauthgssapi: bad GSSAPIINIT version\n")); LOGMISCERR("unsupported GSSAPIINIT version"); ret = AUTHBADCRED; goto error; } ... if (rqst->rqxprt->xpladdrlen > 0) { bindings.acceptoraddrtype = GSSCAFINET; bindings.acceptoraddress.length = 4; bindings.acceptoraddress.value = &rqst->rqxprt->xpladdr.sinaddr.saddr; } else { LOGMISCERR("cannot get local address"); ret = AUTHFAILED; goto error; } ... / done with call args / xdrfree((xdrproct)xdrauthgssapiinitarg, &callarg); ... error: if (creds.clienthandle.length != 0) { PRINTF(("svcauthgssapi: freeing clienthandle len %d\n", (int) creds.clienthandle.length)); xdrfree((xdrproct)xdrauthgssapicreds, &creds); } PRINTF(("\n")); return ret; The unsupported-version branch is sufficient to trigger the leak and does not depend on the less common xpladdrlen <= 0 case. The available package context also shows server-side acceptance of AUTHGSSAPI 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 callarg has already been allocated. Steps to reproduce: 1. Run a service from krb5-1.21.3-8.el100 that accepts legacy AUTHGSSAPI requests, such as kadmind, with ASAN or RSS monitoring enabled. 2. Send RPC requests with auth flavor AUTHGSSAPI, procedure AUTHGSSAPIINIT, and wrapper fields that allow svcgetargs(..., xdrauthgssapiinitarg, &callarg) to decode successfully, such as creds.version=2, authmsg=true, and an empty clienthandle. 3. Set callarg.version to an unsupported value such as 5, and include a large token so the decoded callarg.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 xpladdrlen <= 0 branch, before reaching the sole INIT-path xdrfree((xdrproct)xdrauthgssapiinitarg, &callarg);. Mitigation: Until a fixed package is available, restrict network access to services that accept legacy AUTHGSSAPI to trusted management networks and monitor or rate-limit repeated failing AUTHGSSAPIINIT traffic where possible. If operationally feasible, prefer deployments that do not expose the legacy AUTHGSSAPI path to untrusted clients. Proposed Fix: Free callarg before each early goto error that occurs after successful INIT decode. diff diff --git a/src/lib/rpc/svcauthgssapi.c b/src/lib/rpc/svcauthgssapi.c — a/src/lib/rpc/svcauthgssapi.c +++ b/src/lib/rpc/svcauthgssapi.c @@ -337,6 +337,7 @@ default: PRINTF(("svcauthgssapi: bad GSSAPIINIT version\n")); LOGMISCERR("unsupported GSSAPIINIT version"); + xdrfree((xdrproct)xdrauthgssapiinitarg, &callarg); ret = AUTHBADCRED; goto error; } @@ -361,6 +362,7 @@ } else { LOGMISCERR("cannot get local address"); + xdrfree((xdrproct)xdrauthgssapiinitarg, &callarg); ret = AUTHFAILED; goto error; } ------ This report was generated using AI technology. Always review AI-generated content prior to use

Other sources

The AUTHGSSAPI handler in lib/rpc/svcauthgssapi.c in MIT Kerberos 5 (aka krb5) does not free decoded arguments on certain error paths, which allows remote attackers to cause a denial of service (memory exhaustion in kadmind) via crafted AUTHGSSAPIINIT requests that trigger authentication failures.

— MITRE

Affected Software

6 affected componentsFixes available
redhat/krb5=1.21.3-8.el10_0
debian/krb5*
debian/krb5*
debian/krb5*
debian/krb5<=1.20.1-2+deb12u5, <=1.21.3-5+deb13u1, <=1.22.1-3
alpine/krb5<1.22.3-r0
1.22.3-r0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade alpine/krb5 to a version that resolves this vulnerability.

    Fixed in 1.22.3-r0
  2. Compensating control

    Restrict network access to services accepting legacy AUTH_GSSAPI, such as kadmind, to trusted management networks, and monitor or rate-limit repeated failing AUTH_GSSAPI_INIT requests.

Event History

May 18, 2026
Data Sourced
via Red Hat·03:35 AM
DescriptionSeverityAffected Software
Nov 9, 2026
CVE Published
via MITRE·07:08 PM
Data Sourced
via MITRE·07:08 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·07:16 PM
DescriptionSeverityWeakness
Data Sourced
via OSV·07:16 PM
DescriptionSeverityAffected Software

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203