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: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: 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:    

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