Failures in siw_proc_mpareq (such as version mis-match) cause segfaults

[gregjoyce]

if siw_proc_mpareq() returns a non-zero value, siw_accept_newconn() sets new_cep->listen_cep to NULL. However, a SIW_CM_WORK_MPATIMEOUT work request has already been queued. So when siw_cm_work_handler() runs the state is still in SIW_EPSTATE_AWAIT_MPAREQ and that case does a siw_cep_put on cep->listen_cep which is NULL and causes a segfault.

Also, when siw_accept_newconn() does a goto error it releases the socket but does not set cep->llp.sock to NULL. siw_cm_work_handler() checks for cep->llp.sock != NULL to avoid calling sock_release() but since siw_accept_newconn() did not NULL it, sock_release() is called for the second time on the same socket. This causes a panic.

[gregjoyce]

The following changes prevent the crashes but perhaps there are better fixes.

[gregjoyce]

issue15.patch.txt

[Bernard Metzler]

Thanks Greg!  Applied...     ----- Original message -----From: gregjoyce <[e-mail]>To: zrlio/softiwarp <[e-mail]>Cc: Subscribed <[e-mail]>Subject: [zrlio/softiwarp] Failures in siw_proc_mpareq (such as version mis-match) cause segfaults (#15)Date: Wed, May 31, 2017 11:00 PM  if siw_proc_mpareq() returns a non-zero value, siw_accept_newconn() sets new_cep->listen_cep to NULL. However, a SIW_CM_WORK_MPATIMEOUT work request has already been queued. So when siw_cm_work_handler() runs the state is still in SIW_EPSTATE_AWAIT_MPAREQ and that case does a siw_cep_put on cep->listen_cep which is NULL and causes a segfault. Also, when siw_accept_newconn() does a goto error it releases the socket but does not set cep->llp.sock to NULL. siw_cm_work_handler() checks for cep->llp.sock != NULL to avoid calling sock_release() but since siw_accept_newconn() did not NULL it, sock_release() is called for the second time on the same socket. This causes a panic. —You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or mute the thread.