Bug 951086
| Summary: | sssd segfaults (sssd_be & sssd_pam) with use-after-free error if the back end request takes too long | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Dmitri Pal <dpal> |
| Component: | sssd | Assignee: | Jakub Hrozek <jhrozek> |
| Status: | CLOSED ERRATA | QA Contact: | Kaushik Banerjee <kbanerje> |
| Severity: | urgent | Docs Contact: | |
| Priority: | urgent | ||
| Version: | 6.4 | CC: | apeetham, astrand, chhudson, dpal, ekeck, grajaiya, jgalipea, lmiksik, lslebodn, mkosek, mosvald, mpoole, nc, pbrezina, pep, vchoudha |
| Target Milestone: | rc | Keywords: | ZStream |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | sssd-1.9.2-92.el6 | Doc Type: | Bug Fix |
| Doc Text: |
In case the processing of an LDAP request took longer than the client timeout (60 seconds by default), upon completing the request, the PAM client could have accessed memory that was previously freed due to the client timeout being reached. As a result, the sssd_pam process terminated unexpectedly with a segmentation fault. With this update, SSSD ignores an LDAP request result when it detects that the set timeout of this request has been reached. The sssd_pam process no longer crashes in the aforementioned scenario.
|
Story Points: | --- |
| Clone Of: | 923813 | Environment: | |
| Last Closed: | 2013-11-21 22:16:47 UTC | Type: | Bug |
| 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: | 923813 | ||
| Bug Blocks: | 928849, 960054, 986824 | ||
|
Comment 1
Jakub Hrozek
2013-05-10 15:08:56 UTC
GSS Approved for Hot Fix --------------------------------------------- * Customer impact (or Business case) SSSD crashes ~20 crashes per day and impact 60 servers, with ~1000 distinct users logging in. Verified the BZ on SSSD version: sssd-1.9.2-123.el6.x86_64 Steps followed during verification: 1. Attach sssd_be process to gdb # gdb /usr/libexec/sssd/sssd_be 5267 2. Set the break point at krb5_auth_send (gdb) break krb5_auth_send Breakpoint 1 at 0x7ffcc88f3990 (gdb) cont Continuing. 3. Execute user auth via kerberos server and monitor the backend processes in parallel. # ps -e | grep sss 5266 ? 00:00:00 sssd 5267 ? 00:00:00 sssd_be 5268 ? 00:00:00 sssd_nss 5269 ? 00:00:00 sssd_pam 4. When user authentication pauses at break point, wait till client_idle_timeout expires and hit enter at gdb prompt Breakpoint 1, 0x00007ffcc88f3990 in krb5_auth_send () from /usr/lib64/sssd/libsss_krb5.so (gdb) Continuing. Program received signal SIGTERM, Terminated. 0x00007ffcc88f3990 in krb5_auth_send () from /usr/lib64/sssd/libsss_krb5.so 5. Verify the backend processes. After some time the sssd_be process terminates, see the processes below: # ps -e | grep sss 5266 ? 00:00:00 sssd 5267 ? 00:00:00 sssd_be <defunct> 5268 ? 00:00:00 sssd_nss 5269 ? 00:00:00 sssd_pam 5270 ? 00:00:00 sssd_sudo 6. Quit the gdb session and observe all the backend processes. # ps -e | grep sss 5266 ? 00:00:00 sssd 5268 ? 00:00:00 sssd_nss 5269 ? 00:00:00 sssd_pam 5270 ? 00:00:00 sssd_sudo 5293 ? 00:00:00 sssd_be It can be observed that sssd_be process respawns and sssd_pam remains stable which is expected. With the older builds sssd_pam used to crash. *** Bug 972699 has been marked as a duplicate of this bug. *** *** Bug 994526 has been marked as a duplicate of this bug. *** We're getting quite some reports from the outside about this issue. I'm going to mark the bug as public to avoid users filing duplicates. I went through the comments and I think they are marked private as appropriate. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1680.html |