Filing for book-keeping purposes, this was already fixed in:

- master: 90a83f3c7b49e689d47553a5aa0eb15751846963
- sssd-1.6: 177e08157fa16d14cae55debb187ca1bc1cbe924
- sssd-1.5: 063ed1326daf1d1f588685e7de3197b9caa5b1f0

coverity: =>
description: https://bugzilla.redhat.com/show_bug.cgi?id=746037

{{{
Description of problem:
SSSD's NSS responder process uses an internal hash table. If an SSSD backed is
restarted and the NSS responder reconnects, the responder iterates through
values stored in the hash table. In the rare case nothing has been stored in
the hash table before NSS responder reconnects, the NSS responder would access
uninitialized memory and crash.

Version-Release number of selected component (if applicable):
sssd-1.5.1-55.el6

Steps to Reproduce:
There might be other reproducers but this one has worked for me reliably:
1) configure an LDAP domain
2) lower the "timeout" parameter of the domain so the back end process is more
likely to get restarted by the monitor
3) launch the "check_users" testcase from
https://bugzilla.redhat.com/show_bug.cgi?id=725281
4) wait until monitor restarts the back end - either watch sssd.log or check
the PID of the sssd_be process

Actual results:
sssd_nss crashes when it reconnects to the back end

Expected results:
sssd_nss should not crash
}}}
=> https://bugzilla.redhat.com/show_bug.cgi?id=746037

{{{
Description of problem:
SSSD's NSS responder process uses an internal hash table. If an SSSD backed is
restarted and the NSS responder reconnects, the responder iterates through
values stored in the hash table. In the rare case nothing has been stored in
the hash table before NSS responder reconnects, the NSS responder would access
uninitialized memory and crash.

Version-Release number of selected component (if applicable):
sssd-1.5.1-55.el6

Steps to Reproduce:
There might be other reproducers but this one has worked for me reliably:
1) configure an LDAP domain
2) lower the "timeout" parameter of the domain so the back end process is more
likely to get restarted by the monitor
3) launch the "check_users" testcase from
https://bugzilla.redhat.com/show_bug.cgi?id=725281
4) wait until monitor restarts the back end - either watch sssd.log or check
the PID of the sssd_be process

Actual results:
sssd_nss crashes when it reconnects to the back end

Expected results:
sssd_nss should not crash
}}}

patch: => 0
resolution: => fixed
rhbz: =>
status: new => closed
tests: => 0
testsupdated: => 0
upgrade: => 0

Fields changed

rhbz: => 746037

Fields changed

rhbz: 746037 => [https://bugzilla.redhat.com/show_bug.cgi?id=746037 746037]

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/2100

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.