Hello,

Our UC-KLEE tool found a NULL pointer dereference bug in do_ssl3_write (ssl/s3_pkt.c) when an alert is pending and the SSL_MODE_RELEASE_BUFFERS flag is used. This bug affects the latest 1.0.1 branch.

The code for do_ssl3_write() first checks whether the write buffer is NULL:
644 if (wb->buf == NULL)
645 if (!ssl3_setup_write_buffer(s))
646 return -1;

It then dispatches any pending alerts:
653 /* If we have an alert to send, lets send it */
654 if (s->s3->alert_dispatch)
655 {
656 i=s->method->ssl_dispatch_alert(s);

This call to ssl3_dispatch_alert() calls do_ssl3_write() again:
1501 i = do_ssl3_write(s, SSL3_RT_ALERT, &s->s3->send_alert[0], 2, 0);

Which calls ssl3_write_pending():
852 /* we now just need to write the buffer */
853 return ssl3_write_pending(s,type,buf,len);

Which releases the write buffer if SSL_MODE_RELEASE_BUFFERS is used:
894 if (s->mode & SSL_MODE_RELEASE_BUFFERS &&
895 SSL_version(s) != DTLS1_VERSION && SSL_version(s) != DTLS1_BAD_VER)
896 ssl3_release_write_buffer(s);

When control returns back to the original do_ssl3_write() call, wb->buf has been set to NULL (*after* the NULL check). The NULL pointer dereference then occurs at:
743 *(p++)=type&0xff;

A second check is necessary after the call to ssl->dispatch_alert(), or a counter could be added to ssl_st to avoid releasing the buffers if any callers are performing writes.

-David