Bug 2479240 (CVE-2026-88252) - CVE-2026-88252 sssd: sssd: Denial of Service via responder connection retry loop during file descriptor exhaustion
Summary: CVE-2026-88252 sssd: sssd: Denial of Service via responder connection retry l...
Keywords:
Status: NEW
Alias: CVE-2026-88252
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-05-18 03:59 UTC by OSIDB Bzimport
Modified: 2026-10-06 16:44 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-05-18 03:59:52 UTC
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


Note You need to log in before you can comment on or make changes to this bug.