I'm testing rehandshake processing, and I'm getting segfaults with GnuTLS
2.4.0. Based on the following, it looks to me like hostile TLS servers can make GnuTLS clients corrupt their internal memory, by sending a rehandshake request.

Valgrind's complaint:

==28074== Invalid read of size 4
==28074==    at 0x3B4DE53000: gc_hash_write (gc-libgcrypt.c:431)
==28074==    by 0x3B4DE31020: _gnutls_hash (gnutls_hash_int.c:119)
==28074==    by 0x3B4DE27FA7: _gnutls_send_handshake (gnutls_handshake.c:893)
==28074==    by 0x3B4DE293BB: _gnutls_send_client_hello (gnutls_handshake.c:1861)
==28074==    by 0x3B4DE2B8ED: _gnutls_handshake_client (gnutls_handshake.c:2319)
==28074==    by 0x3B4DE2C687: gnutls_handshake (gnutls_handshake.c:2246)
==28074==    by 0x42026F: x::gnutls::sessionObj::handshake() (sessionobj.C:236)
==28074==    by 0x41FC58: x::gnutls::sessionObj::recv(void*, unsigned long) (sessionobj.C:379)
==28074==    by 0x40CADC: _ZL15testrehandshakev (testsession.C:441)
==28074==    by 0x40E660: main (testsession.C:468)
==28074==  Address 0x64cbce8 is 0 bytes inside a block of size 120 free'd
==28074==    at 0x4A0609F: free (vg_replace_malloc.c:323)
==28074==    by 0x3B4DE2C4A7: _gnutls_handshake_common (gnutls_handshake.c:76)
==28074==    by 0x3B4DE2C631: gnutls_handshake (gnutls_handshake.c:2263)
==28074==    by 0x42026F: x::gnutls::sessionObj::handshake() (sessionobj.C:236)

As far as I can figure out, here's what's happening:

A) Initial handshake.

_gnutls_handshake_hash_init:

  if (session->internals.handshake_mac_handle_init == 0)
    {
        /* This branch is taken.
           handshake_mac_handle_md5, handshake_mac_handle_sha are allocated
        */

      session->internals.handshake_mac_handle_init = 1;
    }

// Handshake continues

Eventually, _gnutls_handshake_hash_buffers_clear() gets called, which
deallocates the handshake_mac_handle_md5 and handshake_mac_handle_sha
structures, however, as far as I can tell, handshake_mac_handle_init remains set to 1.

Then, when the client receives a rehandshake request, and follows through,
_gnutls_handshake_hash_init gets called again, and it will NOT allocate the handshake_mac_handle buffers again, and subsequent functions will scribble all over the deallocated memory.

If my analysis is correct here, a hostile TLS server might force memory corruption in TLS clients, by requesting a handshake.

It looks to me like _gnutls_handshake_hash_buffers_clear() should set session->internals.handshake_mac_handle_init=0