Fedora Account System
Red Hat Associate
Red Hat Customer
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