[Vortex] TLS Failure Segfault

[Jason Dana]

>> Hello all,
> 
> Hi Jason,
> 
>> I am experiencing an issue with a TLS failure, which I believe I have
>> resolved, but wanted to get some clarification.
> 
> OK,
> 
>> Basically, we are getting a segfault when attempting a TLS connection
>> that fails and a subsequent call to vortex_connection_is_ok, with
>> axl_true for destroying the connection if not ok.  What appears to be
>> happening is when the TLS connection is attempted, the original
>> connection is destroyed and then an invalid pointer is returned to the
>> original calling process when TLS fails.  I believe this can be
>> remedied by moving the original connection unref to the end of
>> vortex_tls_invoke_tls_activation.
>> 
>> I have attached a patch for your review.
> 
> I've been reviewing the patch and I see two issues:
> 
> 1) Technically is not possible to receive a wrong connection pointer
>   even after a TLS failure. This is because a new connection object is
>   notified via __vortex_tls_start_negotiation_close_and_notify in all
>   exit branches of that function. This means a good connection
>   reference is always received. 
> 
>   The only way to receive a wrong pointer is that the following is
>   failling (around vortex_tls.c:982) which is not checked:
> 
>   connection = vortex_connection_new_empty_from_connection (ctx, socket, connection_aux, VortexRoleInitiator);
> 
>   Now, the function also checks that pointer but I suspect this
>   is not the case (svn rev 4995).

When utilizing vortex_tls_set_auto_tls and then vortex_connection_new, should the connection returned be the newly created TLS attempted connection?  It appears we are receiving the original, non-TLS, connection back.

> 2) The patch proposes to move the unref code until the end, but that
>   will cause leaks due to all wrong branches before (wrong greetings,  
>   TLS handshake failure, ....) where the reference is not finished.

My apologies, upon closer inspection of the valgrind output it does appear that when segfaulting and my patch have the same memory leaks.  This appears to be due to the TLS connection being lost.

> Just a question about your description. What's the connection being
> checked with vortex_connection_is_ok (conn, axl_true) after tls failure?
> The one returned by the tls activation or the starting connection?
> 
> You must forget about the starting connection when you call to activate
> TLS because that function may replace your reference, even after failure
> (something may go wrong after TLS finished right, for example BEEP
> session doesn't agree)....

How should the connection be checked?  Rather, how should the new, failed, TLS connection be acquired?  I cannot seem to locate a method that will retrieve the failed TLS connection that has been created.  When the TLS connection succeeds, the connection returned is the TLS-ificated connection, but not when it fails.

Thank you!

Jason

> Best Regards,
> 
>> Jason
>> 
>> _______________________________________________
>> Vortex mailing list
>> Vortex at lists.aspl.es
>> http://lists.aspl.es/cgi-bin/mailman/listinfo/vortex
> 
> -- 
> Francis Brosnan Blázquez <francis.brosnan at aspl.es>
> ASPL
> 91 134 14 22 - 91 134 14 45 - 91 116 07 57
> 
> AVISO LEGAL
> 
> Este mensaje se dirige exclusivamente a su destinatario. Los datos
> incluidos en el presente correo son confidenciales y sometidos a secreto
> profesional, se prohíbe divulgarlos, en virtud de las leyes vigentes. Si
> usted no lo es y lo ha recibido por error o tiene conocimiento del mismo
> por cualquier motivo, le rogamos que nos lo comunique por este medio y
> proceda a destruirlo o borrarlo.
> 
> En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de
> diciembre, de Protección de Datos de Carácter Personal, le informamos de
> que sus datos de carácter personal, recogidos de fuentes accesibles al
> público o datos que usted nos ha facilitado previamente, proceden de
> bases de datos propiedad de Advanced Software Production Line, S.L.
> (ASPL). No obstante, usted puede ejercitar sus derechos de acceso,
> rectificación, cancelación y oposición dispuestos en la mencionada Ley
> Orgánica, notificándolo por escrito a:
> ASPL - Protección Datos, C/Antonio Suárez 10 A-102, 28802, Alcalá de
> Henares (Madrid).
>