Re: [radsecproxy] race condition when losing ssl connection
20 Nov
2017
20 Nov
'17
1:41 p.m.
Steffen Klemer <klemer(a)dfn.de> wrote
Fri, 17 Nov 2017 15:38:08 +0100:
I think this is a race condition among 2 threads in
the lines
https://git.nordu.net/?p=radsecproxy.git;a=blob;f=tls.c;h=567a6be3491751cb7…
https://git.nordu.net/?p=radsecproxy.git;a=blob;f=tls.c;h=567a6be3491751cb7…
(i.e. client->ssl will be nulled before SSL_write() is called )
Thanks for finding and report this (with a fix, none the less!).
This looks like RADSECPROXY-47 [0] which was identified earlier but
sadly never addressed.
[0] https://project.nordu.net/projects/RADSECPROXY/issues/RADSECPROXY-47
The attached patch against 1.6.9 fixes this while
trying to be non-invasive to the code flow. There is still the chance of running SSL_write
on a 'broken' tls connection but this is handled by openssl and 'cnt'
anyway -- one could perhaps adjust the debug message then :).
How do you mean openssl and 'cnt' handle this?
An alternative fix might be to simply check for client->ssl != NULL
before calling SSL_write() outside of the replyq->mutex lock. Did you
consider this? Worth investigating?