CVE-2026-88252: Sssd: sssd: denial of service via responder connection retry loop during file descriptor exhaustion

AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: Local DoS in responder accept() path via EMFILE/ENFILE retry spin: a local user who can reach an affected responder UNIX socket can force accept() failures under file descriptor exhaustion and trigger a busy retry loop that stalls responder service. Requirements to exploit: Local access to a responder UNIX socket serviced by acceptfdhandler(), plus the ability to create and hold enough concurrent connections to push the responder into EMFILE or ENFILE while keeping the listen queue non-empty. Practical reachability depends on an affected responder being enabled and locally reachable. Component affected: sssd-2.12.0-1.el10, src/responder/common/respondercommon.c, acceptfdhandler() Version affected: sssd-2.12.0-1.el10; practical exploitation depends on an enabled responder using this common local socket accept path 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:H/PR:N/UI:N/S:U/C:N/I:N/A:H - 5.5 (MEDIUM) AV:L - exploitation requires local access to a reachable responder UNIX socket. AC:H - the attacker must sustain responder-side file descriptor exhaustion and keep the listen queue populated so the handler repeatedly wakes without making progress. PR:N - based on the available evidence, no prior privileges beyond local access are required to trigger the condition. UI:N - no user interaction is needed. S:U - the impact remains within the affected responder 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 - the responder can enter a high-CPU retry loop and stop servicing legitimate requests. Impact: Moderate. The issue can substantially degrade availability of an enabled responder, but the established impact is local and availability-only, and exploitation depends on local socket reachability plus sustained file descriptor pressure. Under Red Hat's severity guidance, that fits Moderate more closely than Important or Critical. Embargo: no Reason: The available evidence supports a local denial of service rather than system compromise, confidentiality loss, or integrity loss, and the issue does not present a credible wormable or remotely exploitable scenario. Acknowledgement: Aisle Research Vulnerability Details: acceptfdhandler() accepts incoming connections for responder sockets. When accept() fails, the handler logs the error, frees the client context, and returns immediately: c cctx->cfd = accept(rctx->lfd, (struct sockaddr )&cctx->addr, &len); if (cctx->cfd == -1) { DEBUG(SSSDBGCRITFAILURE, "Accept failed [%s]\n", strerror(errno)); tallocfree(cctx); return; } The listener remains persistently registered as readable: c rctx->lfde = teventaddfd(rctx->ev, rctx, rctx->lfd, TEVENTFDREAD, acceptfdhandler, acceptctx); No EMFILE/ENFILE-specific backoff, temporary TEVENTFDNOTREADABLE, or reserved-fd drain logic is present in this path. If the responder runs out of file descriptors while additional local connections remain queued, the event loop can repeatedly re-enter acceptfdhandler() with no forward progress. Based on the available evidence, the result is sustained CPU consumption and stalled legitimate requests, not demonstrated confidentiality or integrity impact. Steps to reproduce: 1. Run sssd-2.12.0-1.el10 with a responder using this common UNIX socket accept path, such as an NSS or PAM responder. 2. Set a low responder file descriptor limit for quick reproduction, for example fdlimit = 256, and restart the responder. 3. As an unprivileged local user, open and hold many concurrent connections to the responder socket until the responder exhausts its available file descriptors. 4. Continue making connection attempts so the listen queue remains non-empty. 5. Observe repeated Accept failed [Too many open files] log messages, sustained responder CPU use, and stalled or timed-out legitimate requests. 6. Reduce the connection pressure or restart the responder to recover service. Mitigation: Where operationally possible, restrict access to affected responder UNIX sockets and avoid unnecessarily low fdlimit settings. Monitoring for repeated Accept failed [Too many open files] log entries can help detect the condition early. These measures reduce exposure but do not address the missing backoff in the accept() failure path; if the condition is triggered, reducing connection pressure or restarting the affected responder restores service. Proposed Fix: A minimal fix is to treat EMFILE and ENFILE as a special case, temporarily clear readability on the listening fd, and re-enable it on a short timer so the event loop does not spin indefinitely. diff diff --git a/src/responder/common/respondercommon.c b/src/responder/common/respondercommon.c index 0000000..0000000 100644 — a/src/responder/common/respondercommon.c +++ b/src/responder/common/respondercommon.c @@ struct acceptfdctx { struct respctx rctx; connectionsetupt connectionsetup; + struct teventtimer resumeaccepttimer; }; + +static void acceptresumetimer(struct teventcontext ev, + struct teventtimer te, + struct timeval tv, + void pvt) +{ + struct acceptfdctx acceptctx = tallocgettype(pvt, struct acceptfdctx); + acceptctx->resumeaccepttimer = NULL; + TEVENTFDREADABLE(acceptctx->rctx->lfde); +} @@ cctx->cfd = accept(rctx->lfd, (struct sockaddr )&cctx->addr, &len); if (cctx->cfd == -1) { DEBUG(SSSDBGCRITFAILURE, "Accept failed [%s]\n", strerror(errno)); + int err = errno; + DEBUG(SSSDBGCRITFAILURE, "Accept failed [%s]\n", strerror(err)); + + if ((err == EMFILE || err == ENFILE) && + acceptctx->resumeaccepttimer == NULL) { + struct timeval tv = teventtimevalcurrentofs(0, 200000); / 200ms / + TEVENTFDNOTREADABLE(fde); + acceptctx->resumeaccepttimer = teventaddtimer(ev, acceptctx, tv, + acceptresumetimer, + acceptctx); + } tallocfree(cctx); return; }

------ This report was generated using AI technology. Always review AI-generated content prior to use

— Red Hat