1. Please, see the next OpenSSL calls.
BIO_pending(ssock->ossl_wbio)
SSL_do_handshake(ssock->ossl_ssl)
SSL_read(ssock->ossl_ssl, data_, size_)
SSL_write(ssock->ossl_ssl, data, (int)size)
All of these calls could use "SSL object when it has encountered a fatal error" or
the SSL object was destroyed.
My patch added this checking, but you removed it.
Why?
2. The destroy_ssl doesn't destroy write_mutex.
The write_mutex is destroyed in pj_ssl_sock_close.
My patch does nothing with this, so this potential race existed before.
The ssl should be destroyed as soon as possible to release a TCP socket/port.
To fix potential race issue with write_mutex the group locking could use.
So I combined my patch with your group locking patch.
Attached a new patch.
Regards,
Alexei
Wednesday, October 12, 2016, 8:36:13 AM, you wrote:
Hi Alexei, When doing the review your patch, we identified another potential race issue which might occur. e.g: write_mutex get destroyed before send() is called. We feel that using group lock will solve these issues. As you can see from the patch, the reset_ssl_sock_state() will not destroy the ssl. We have moved all the code of destroying ssl and write_mutex to the ssl_on_destroy() which is called when the group lock is no longer held or reference count reach 0. As for your concern regarding the call to BIO_pending() on a closed socket, it shouldn't be a problem since we don't use OpenSSL for the socket operation. Or, maybe I'm missing something here? Best Regards, Riza On Tue, Oct 11, 2016 at 10:44 PM, Alexei Gradinari <alex2grad@xxxxxxxxx> wrote: Hello Riza, Could you, please, explain why did you remove all checking on openssl calls from my patch? Your patch didn't fix race condition. Imagine one thread calls reset_ssl_sock_state while another thread calls BIO_pending(ssock->ossl_wbio) on already closed socket. Pleas, look at commit 189e20c68c2399782034fec9f65d6b9ee88aac3d https://mta.openssl.org/pipermail/openssl-commits/2015-May/001035.html Reusing an SSL object when it has encountered a fatal error can have bad consequences. This is a bug in application code not libssl but libssl should be more forgiving and not crash. P.S. I don't understand why my patch isn't acceptable for you. Could you, please, explain. Regards, Alexei Sunday, October 9, 2016, 7:51:54 PM, you wrote:
|
Attachment:
pjproject-svn-ssl_write-NEW.patch
Description: Binary data
_______________________________________________ Visit our blog: http://blog.pjsip.org pjsip mailing list pjsip@xxxxxxxxxxxxxxx http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org