[gnutls-dev] RFH gnutls related crash of exim4 on x86_64 (Bug#412886)

Simon Josefsson simon at josefsson.org
Tue May 15 21:53:24 CEST 2007

Andreas Metzler <ametzler at downhill.at.eu.org> writes:

> #0  _gnutls_read_uint16 (data=0x0) at gnutls_num.c:120
> 120     gnutls_num.c: No such file or directory.
>         in gnutls_num.c
> (gdb) bt
> #0  _gnutls_read_uint16 (data=0x0) at gnutls_num.c:120
> #1  0x00002ba3e841bfc9 in _gnutls_proc_rsa_client_kx (session=0x629e10,
>     data=0x0, _data_size=61) at auth_rsa.c:213

Interesting, data is NULL here, as invoked from this function:

> #2  0x00002ba3e84171e9 in _gnutls_recv_client_kx_message (session=0x629e10)
>     at gnutls_kx.c:333

The function reads:

      ret =
	_gnutls_recv_handshake (session, &data,
      if (ret < 0)
	return ret;

      ret =
	gnutls_process_client_kx (session, data, datasize);
      gnutls_free (data);
      if (ret < 0)
	return ret;

Reading the source for _gnutls_recv_handshake, it seems to be possible
for it to return >= 0 if the code received a
I'm not 100 % certain of this though.

> #3  0x00002ba3e8412c72 in _gnutls_handshake_server (session=0x629e10)
>     at gnutls_handshake.c:2259
> #4  0x00002ba3e841236b in gnutls_handshake (session=0x629e10)
>     at gnutls_handshake.c:1908
> #5  0x00000000004604a7 in tls_server_start (require_ciphers=0x0)
>     at tls-gnu.c:838
> #6  0x0000000000459339 in smtp_setup_msg () at smtp_in.c:3212
> #7  0x0000000000418fc3 in handle_smtp_call (listen_sockets=0x5e3cd0,
>     listen_socket_count=6, accept_socket=0, accepted=0x0) at daemon.c:495
> #8  0x000000000041a55c in daemon_go () at daemon.c:1815
> #9  0x000000000042848b in main (argc=7, cargv=0x0) at exim.c:3922
> ---
> Please let me know if you want any more information.

If you can reproduce the crash in gdb, try getting a backtrace using 'bt
full', and invoke 'up' until you are in the _gnutls_recv_handshake stack
frame, then 'p recv_type'.  If it is indeed
think we have diagnosed the cause.

It may be that the client got confused and started sending client
hello's all over, and this confused the GnuTLS state machine.  Of
course, it shouldn't be possible to crash it.

Debugging exactly why the other end sends these funny messages would be
the next step, I'm not sure that if we would fix the crash that the
hosts will be able to handshake properly.

Any chance to contact the remote host to find out what software it is


More information about the Gnutls-devel mailing list