#1869 pam responder segfaults if the client disconnects before the operation finishes
Closed: Fixed None Opened 11 years ago 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)

Fields changed

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

1.9 (and possibly 1.5) backports are coming up.

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.9.5

Fields changed

resolution: => fixed
status: assigned => closed

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

7 years ago

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.

Login to comment on this ticket.

Metadata