I have found a problem with SSL_MODE_RELEASE_BUFFERS and with
multithreading when using version 1.0.1e.  This issue has already been
logged by someone at rt.openssl.org and the ticket # is 2167.

The issue is when the buffer is released by ssl3_release_read_buffer(),
there may still be data left in the buffer (s->s3->rbuf.left != 0). With
single threading, when another read occurs, the same buffer is reused
during a call to ssl3_setup_read_buffer() so the data is still there and
can be read and processed so it works fine. When running with multiple
threads, the buffer is shared in a pool and another thread may have gotten
that buffer already. If the call to ssl3_setup_read_buffer() returns a new
buffer, it assume the data is still there but will run into parsing error
with the record.

The fix I did was to check s->s3->rbuf.left and only call
ssl3_release_read_buffer() when s->s3->rbuf.left is zero.  This delays the
release of the buffer until all the data has processed.  The fix seems to
fix the issue.

Here is a patch of the changes:


--- s3_pkt_original.c   2013-02-11 10:26:04 -0500
+++ s3_pkt.c    2013-09-18 10:15:47 -0400
@@ -1055,7 +1055,7 @@
                {
                s->rstate=SSL_ST_READ_HEADER;
                rr->off=0;
-               if (s->mode & SSL_MODE_RELEASE_BUFFERS)
+               if (s->mode & SSL_MODE_RELEASE_BUFFERS && s->s3->rbuf.left
== 0)
                    ssl3_release_read_buffer(s);
                }
            }





Best Regards,

Benson Kwok
Development 
Www.air-watch.com

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to