[stunnel-users] Premature socket closure - race condition bug?

[Graham Nayler (work)]

Ah..another possible problem with your solution...or alternatively with my 
understanding of the socket interface. What happens if the remote program 
submits the data, stunnel unloads the socket, and only then does the remote 
program close the socket? Will the s_poll_wait be triggered on the HUP alone 
(I guess yes)? If not, then stunnel will hang until something submits more 
data. But if triggered only on the HUP, the lines checking for internal 
failures will see an exit with no read or write data waiting, and take the 
longjmp() after "s_poll_wait returned %d, but no descriptor is ready". In my 
suggested version it did an additional check for sock_rd_hup to cope with 
just this scenario.

-----Original Message----- 
From: Graham Nayler (work)
Sent: Monday, September 22, 2014 12:54 PM
To: stunnel-users at stunnel.org
Subject: Re: [stunnel-users] Premature socket closure - race condition bug?

Since submitting my original patch, I've realised there is a possible
scenario that both my solution, and I think yours as well, still fails on:
we're assuming that once the readsocket call has returned, there's nothing
left in the socket buffer. Is this not dependent on the size of the data
submitted by the remote program, the capacity of the socket buffer itself,
and the space remaining in c->sock_buf after c->sock_ptr? I.e. there could
still be data in the socket if the buffered data were longer than that
returned by readsocket? Should stunnel not repoll/check the socket to ensure
that POLLIN is not set before taking any action on POLLUP? Maybe
s_poll_hup() should only be allowed to return POLLIN if POLLHUP is not set?

Graham

-----Original Message----- 
From: Graham Nayler (work)
Sent: Monday, September 22, 2014 12:13 PM
To: stunnel-users at stunnel.org
Subject: Re: [stunnel-users] Premature socket closure - race condition bug?

Compiled and installed on the Linux Mint server and looking fine so far
using my test example. If nothing shows up in the next few hours of normal
running it should be fine.

It's of lower priority, but I'd like to update the client machines as well
when the release goes official. This may be better in a separate thread, or
already exist in an FAQ I've not found, but
as I have about 50 (currently, eventually >80) sites to update (mostly
Windows 7, some XPSP3), is there a way for the Windows install to be run
unattended? Failing that, is there a list, or way to generate a list, of
updated binaries + reg/config entries so I can make myself an unattended
install/upgrade? Most sites are currently on 5.01, but some are still on
4.56.

-----Original Message----- 
From: Michal Trojnara
Sent: Monday, September 22, 2014 11:00 AM
To: stunnel-users at stunnel.org
Subject: Re: [stunnel-users] Premature socket closure - race condition bug?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Graham Nayler wrote:
> In the failure scenario though, the returned status was
> (POLLIN|POLLHUP).

Great work.  I indeed forgot that the POLLHUP condition may be set
while some buffered data is still available.

Could you try:
https://www.stunnel.org/downloads/beta/stunnel-5.05b1.tar.gz
?

Mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlQf80IACgkQ/NU+nXTHMtG3pACfeYvvrabt8TAM7CsOP1fm9nod
/0UAoPpF7W5FkGjzb1u3E+6ZRHtoyi2L
=p6UY
-----END PGP SIGNATURE-----
_______________________________________________
stunnel-users mailing list
stunnel-users at stunnel.org
https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users

_______________________________________________
stunnel-users mailing list
stunnel-users at stunnel.org
https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users

_______________________________________________
stunnel-users mailing list
stunnel-users at stunnel.org
https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users