#1869 pam responder segfaults if the client disconnects before the operation finishes
Closed: Fixed Opened by jhrozek.

The pam request structure in the PAM responder is allocated on the client context. If the client disconnects while there is a long-running operation in the responder which finishes after the clients has disconnected, then the responder tries to access the structure that was allocated on the client context and segfaults.

Here is the valgrind log:

==26394== Invalid read of size 8
==26394==    at 0x3560A024AC: talloc_get_name (talloc.c:238)
==26394==    by 0x3560A027ED: talloc_check_name (talloc.c:956)
==26394==    by 0x40BBBA: pam_dp_process_reply (pamsrv_dp.c:42)
==26394==    by 0x356460C7F9: complete_pending_call_and_unlock (dbus-connection.c:2170)
==26394==    by 0x356460E010: dbus_connection_dispatch (dbus-connection.c:4296)
==26394==    by 0x424491: sbus_dispatch (sssd_dbus_connection.c:104)
==26394==    by 0x3562A034D2: tevent_common_loop_timer_delay (tevent_timed.c:254)
==26394==    by 0x3562A0509A: std_event_loop_once (tevent_standard.c:537)
==26394==    by 0x3562A0268F: _tevent_loop_once (tevent.c:490)
==26394==    by 0x3562A026FA: tevent_common_loop_wait (tevent.c:591)
==26394==    by 0x426F40: server_loop (server.c:526)
==26394==    by 0x407E14: main (pamsrv.c:246)
==26394==  Address 0x4c94920 is 48 bytes inside a block of size 136 free'd
==26394==    at 0x4A05D21: free (vg_replace_malloc.c:325)
==26394==    by 0x3560A02DF7: _talloc_free_internal (talloc.c:669)
==26394==    by 0x3560A03356: _talloc_free (talloc.c:631)
==26394==    by 0x42E1FB: idle_handler (responder_common.c:421)
==26394==    by 0x3562A034D2: tevent_common_loop_timer_delay (tevent_timed.c:254)
==26394==    by 0x3562A05367: std_event_loop_once (tevent_standard.c:495)
==26394==    by 0x3562A0268F: _tevent_loop_once (tevent.c:490)
==26394==    by 0x3562A026FA: tevent_common_loop_wait (tevent.c:591)
==26394==    by 0x426F40: server_loop (server.c:526)
==26394==    by 0x407E14: main (pamsrv.c:246)

Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=923813 (Red Hat Enterprise Linux 5)

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

Fields changed

owner: somebody => jhrozek
patch: 0 => 1
status: new => assigned

  • master: a28391f68a09eaedbe1a515f513ca56bbb94d7a5

1.9 (and possibly 1.5) backports are coming up.

  • sssd-1-9: 9ef2f2a4abba3d10c3aeeba0e99a6f2374f2a5ba

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.9.5

Fields changed

resolution: => fixed
status: assigned => closed

Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=963583 (Fedora)

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

Metadata Update from @jhrozek:
- Issue assigned to jhrozek
- Issue set to the milestone: SSSD 1.9.5

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/2911

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.

Metadata