Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process.

A flaw was found in 389-ds-base. The server reads from the client socket in bulk rather than one LDAP message at a time. If a client sends a complete LDAP operation followed by the first bytes of a second, never-completed LDAPMessage, connection_read_operation() dispatches the first operation but, because bytes remain in the connection's read buffer, sets a 'more data available' flag. connection_threadmain() then requeues the same connection onto the shared work queue for a second worker thread to service, before the first worker's result has been flushed via connection_dispatch_operation(). The second worker blocks in its read loop, holding the connection mutex, until nsslapd-ioblocktimeout expires, which also prevents the first worker from delivering its already-computed result. Repeating this pattern across ceil(nsslapd-threadnumber / nsslapd-maxthreadsperconn) unauthenticated sockets (as few as ~7 on a 32-worker pool, up to ~103 on the largest shipped pool size) occupies the server's entire worker-thread pool, denying service to all client classes (anonymous search, bind, LDAPS, bound search/write) for as long as the attacker maintains the sockets, at a cost of roughly 1.7 bytes/second. This is exploitable under the default configuration (nsslapd-maxthreadsperconn=5, nsslapd-ioblocktimeout=10000, nsslapd-connection-buffer=on) with no authentication, no malformed protocol data, and no privileged precondition. Independently reproduced both statically (against upstream 389-ds-base-3.3.0 source) and dynamically (against the actual RHEL 9.6 z-stream package 389-ds-base-2.6.1-6.el9_6, under a default/stock instance configuration, in an isolated sandbox), with source-diff review confirming RHEL 8 and RHEL 10 packaging does not alter the vulnerable code path either.