Bug 2479240 (CVE-2026-88252)
| Summary: | CVE-2026-88252 sssd: sssd: Denial of Service via responder connection retry loop during file descriptor exhaustion | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | OSIDB Bzimport <bzimport> |
| Component: | vulnerability | Assignee: | Product Security DevOps Team <prodsec-dev> |
| Status: | NEW --- | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | akhatavk, aos-team-art-private, asdas, dpaolell, jdelft, jupierce, lgarciaa, mbiarnes, ppalepu, ppostler, prdhamdh, rhel-process-autobot, security-response-team, sghai, sidsharm, suppawar, vlaad, watson-tool-maintainers |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | --- | |
| Doc Text: |
A flaw was found in sssd. A local user can cause a Denial of Service (DoS) by exhausting the responder service's available file descriptors (system handles used for open connections). By opening and maintaining many concurrent connections to a responder socket while continuing to queue new connection attempts, an attacker can trigger an unthrottled retry loop. This condition leads to high CPU utilization and stalls the service, preventing legitimate identity and authentication requests from being processed.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 2547127 | ||
| Bug Blocks: | |||
AI_ONLY_REPORT 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 `accept_fd_handler()`, 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/responder_common.c`, `accept_fd_handler()` 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: `accept_fd_handler()` 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(SSSDBG_CRIT_FAILURE, "Accept failed [%s]\n", strerror(errno)); talloc_free(cctx); return; } ``` The listener remains persistently registered as readable: ```c rctx->lfde = tevent_add_fd(rctx->ev, rctx, rctx->lfd, TEVENT_FD_READ, accept_fd_handler, accept_ctx); ``` No `EMFILE`/`ENFILE`-specific backoff, temporary `TEVENT_FD_NOT_READABLE`, 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 `accept_fd_handler()` 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 `fd_limit = 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 `fd_limit` 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/responder_common.c b/src/responder/common/responder_common.c index 0000000..0000000 100644 — a/src/responder/common/responder_common.c +++ b/src/responder/common/responder_common.c @@ struct accept_fd_ctx { struct resp_ctx *rctx; connection_setup_t connection_setup; + struct tevent_timer *resume_accept_timer; }; + +static void accept_resume_timer(struct tevent_context *ev, + struct tevent_timer *te, + struct timeval tv, + void *pvt) +{ + struct accept_fd_ctx *accept_ctx = talloc_get_type(pvt, struct accept_fd_ctx); + accept_ctx->resume_accept_timer = NULL; + TEVENT_FD_READABLE(accept_ctx->rctx->lfde); +} @@ cctx->cfd = accept(rctx->lfd, (struct sockaddr *)&cctx->addr, &len); if (cctx->cfd == -1) { DEBUG(SSSDBG_CRIT_FAILURE, "Accept failed [%s]\n", strerror(errno)); + int err = errno; + DEBUG(SSSDBG_CRIT_FAILURE, "Accept failed [%s]\n", strerror(err)); + + if ((err == EMFILE || err == ENFILE) && + accept_ctx->resume_accept_timer == NULL) { + struct timeval tv = tevent_timeval_current_ofs(0, 200000); /* 200ms */ + TEVENT_FD_NOT_READABLE(fde); + accept_ctx->resume_accept_timer = tevent_add_timer(ev, accept_ctx, tv, + accept_resume_timer, + accept_ctx); + } talloc_free(cctx); return; } ``` ------ This report was generated using AI technology. Always review AI-generated content prior to use