A race condition was found in the way 389-ds-base handles persistent search, resulting in a crash if the server is under load. An anonymous attacker could use this flaw to trigger a denial of service.
The bug is related to incoming connection handling in DS. A connection data structure contains a refcnt. The refcnt accounts the number of pending requests. When a connection needs to be cleanup (upon closure, timeout...) the core server waits for refcnt to be 0. It basically waits for all pending requests to complete before cleaning the structure.
The refcnt does not account specific LDAP request (persistent search), so if an event occurs on the connection (closure) the core server may reset the structure although a request is still going on.
Anonymous user are allowed to trigger a persistent search so in theory anyone sending persistent search and closing the connection hits that bug.
Under normal use, most of the time the problem is not detected. Sometime there are error written in the log when an invalid refcnt is found. But depending on dispatch dynamic of the threads handling connection event it can crash.
Name: Thierry Bordaz (Red Hat)
Upstream fix :
- Ticket 49768 - Under network intensive load persistent search can erronously decrease connection refcnt
This issue has been addressed in the following products:
Red Hat Enterprise Linux 7
Via RHSA-2018:2757 https://access.redhat.com/errata/RHSA-2018:2757