REDHAT-BUG-2478792: High severity redhat/krb5 vulnerability

Published May 18, 2026
·
Updated

AIONLYREPORT package: krb5-1.21.3-8.el100 ------ Summary: DoS in kadmind via NULL dereference in unauthorized policy logging (logunauth): an authenticated but unauthorized client can send a crafted policy RPC request with a NULL policy name and crash kadmind through strlen(NULL) in the unauthorized logging path. Requirements to exploit: A running and reachable kadmind instance, a valid principal that can issue admin RPC requests but lacks policy-administration rights, and the ability to send a crafted RPC request that encodes the policy name as an XDR nullstring (size=0) instead of relying on normal kadmin CLI validation. Component affected: krb5 kadmind policy RPC handling in src/kadmin/server/serverstubs.c (logunauth(), createpolicy2svc(), deletepolicy2svc(), modifypolicy2svc(), getpolicy2svc()), with NULL policy-name inputs admitted by src/lib/kadm5/kadmrpcxdr.c Version affected: krb5-1.21.3-8.el100 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 kadmind RPC requests. AC:L - Exploitation requires only a crafted policy RPC request with a NULL XDR string; no race or unusual environmental condition was established. PR:L - The attacker must authenticate, but does not need policy-administration privileges. UI:N - No user interaction is required. S:U - The crash affects the same kadmind security scope. C:N - No confidentiality impact was established. I:N - No integrity impact was established. A:H - The NULL dereference can terminate kadmind, denying administrative service until it is restarted. Impact: Important. This issue allows a remote authenticated attacker to cause a denial of service in kadmind, which aligns with Red Hat's Important category for flaws that allow remote users to impact availability. It is not Critical because authentication is required and no confidentiality, integrity, or code-execution impact was established. Embargo: no Reason: The available evidence supports an authenticated denial of service in an administrative daemon, with no demonstrated confidentiality or integrity impact and straightforward operational mitigations while a fix is prepared. Acknowledgement: Aisle Research Vulnerability Details: In src/kadmin/server/serverstubs.c, logunauth() calls strlen(target) without first checking whether target is NULL: c static int logunauth( char op, char target, gssbuffert client, gssbuffert server, struct svcreq rqstp) { sizet tlen, clen, slen; char tdots, cdots, sdots; tlen = strlen(target); truncname(&tlen, &tdots); clen = client->length; truncname(&clen, &cdots); slen = server->length; truncname(&slen, &sdots); / okay to cast lengths to int because truncname limits max value / return krb5klogsyslog(LOGNOTICE, ("Unauthorized request: %s, %.s%s, " "client=%.s%s, service=%.s%s, addr=%s"), op, (int)tlen, target, tdots, (int)clen, (char )client->value, cdots, (int)slen, (char )server->value, sdots, clientaddr(rqstp->rqxprt)); } The policy RPC handlers createpolicy2svc(), deletepolicy2svc(), modifypolicy2svc(), and getpolicy2svc() pass request-derived arg->rec.policy or arg->name directly into logunauth() when authorization fails. Those policy-name fields are decoded with xdrnullstring(), and a zero-length XDR string is accepted and decoded to NULL. As a result, an authenticated caller can send a crafted policy request with a NULL policy name, force the unauthorized branch, and reach strlen(NULL) in the logging path. The success-path logging already substitutes "(null)" for NULL names, so the crash is specific to unauthorized-request logging. Steps to reproduce: 1. Run kadmind. 2. Authenticate as a valid principal that can issue admin RPC requests but lacks policy-administration rights. 3. Send one of CREATEPOLICY, DELETEPOLICY, MODIFYPOLICY, or GETPOLICY with the policy name encoded as an XDR nullstring (size=0), so the server decodes the field to NULL. 4. Ensure the request follows the unauthorized branch. 5. logunauth(..., target=NULL, ...) executes strlen(NULL), causing a SIGSEGV and denial of kadmind service. Normal kadmin client-side checks may reject NULL names, so reproduction appears to require a crafted RPC request rather than the stock CLI. Mitigation: Restrict network access to kadmind to trusted administrative hosts and limit which principals can authenticate to the admin RPC service. Where the service is not required, disabling kadmind removes reachability. These measures reduce exposure but do not remove the vulnerable code path from a reachable instance. Proposed Fix: A minimal fix is to make logunauth() handle a NULL target the same way logdone() already does. diff diff --git a/src/kadmin/server/serverstubs.c b/src/kadmin/server/serverstubs.c — a/src/kadmin/server/serverstubs.c +++ b/src/kadmin/server/serverstubs.c @@ -384,6 +384,9 @@ logunauth( sizet tlen, clen, slen; char tdots, cdots, sdots; + if (target == NULL) + target = "(null)"; + tlen = strlen(target); truncname(&tlen, &tdots); ------ This report was generated using AI technology. Always review AI-generated content prior to use

Affected Software

1 affected component
redhat/krb5=1.21.3-8.el10_0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Configuration

    Disable kadmind where the administrative service is not required.

    kadmind service state = disabled
  2. Compensating control

    Restrict network access to kadmind to trusted administrative hosts and limit which principals can authenticate to the admin RPC service.

Event History

May 18, 2026
Data Sourced
via Red Hat·03:45 AM
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