[gnutls-devel] gnutls-cli-debug segfaults after checking for inappropriate fallback (RFC7507) support

Andreas Metzler ametzler at bebt.de
Sat Nov 12 14:07:58 CET 2016


this is http://bugs.debian.org/844061 subnmitted by Daniel Kahn Gillmor:
I get a segfault from:

   gnutls-cli-debug --port 853 dns.cmrg.net
(gdb) run --port 853 dns.cmrg.net
Starting program: /usr/bin/gnutls-cli-debug --port 853 dns.cmrg.net
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Warning: getservbyport(853) failed. Using port number as service.
GnuTLS debug client 3.5.5
Checking dns.cmrg.net:853
                             for SSL 3.0 (RFC6101) support... no
                        whether we need to disable TLS 1.2... no
                        whether we need to disable TLS 1.1... no
                        whether we need to disable TLS 1.0... no
                        whether %NO_EXTENSIONS is required... no
                               whether %COMPAT is required... no
                             for TLS 1.0 (RFC2246) support... yes
                             for TLS 1.1 (RFC4346) support... yes
                             for TLS 1.2 (RFC5246) support... yes
                                  fallback from TLS 1.6 to... TLS1.2
              for inappropriate fallback (RFC7507) support... yes

Program received signal SIGSEGV, Segmentation fault.
copy_record_version (version=0x555555790a5c "\003\002", htype=4294967295, 
    session=0x55555578d370) at record.c:370
370	record.c: No such file or directory.
(gdb) bt
#0  copy_record_version (version=0x555555790a5c "\003\002", htype=4294967295, 
    session=0x55555578d370) at record.c:370
#1  _gnutls_send_tlen_int (session=session at entry=0x55555578d370, 
    type=type at entry=GNUTLS_ALERT, htype=htype at entry=4294967295, 
    epoch_rel=epoch_rel at entry=70001, _data=_data at entry=0x7fffffffe340, 
    data_size=data_size at entry=2, min_pad=0, mflags=1) at record.c:496
#2  0x00007ffff7ac7c28 in _gnutls_send_int (mflags=1, data_size=2, 
    _data=0x7fffffffe340, epoch_rel=70001, htype=4294967295, 
    type=GNUTLS_ALERT, session=0x55555578d370) at ./record.h:43
#3  gnutls_alert_send (session=session at entry=0x55555578d370, 
    level=level at entry=GNUTLS_AL_WARNING, desc=desc at entry=GNUTLS_A_CLOSE_NOTIFY)
    at alert.c:165
#4  0x00007ffff7aa583c in gnutls_bye (session=0x55555578d370, 
    how=GNUTLS_SHUT_WR) at record.c:297
#5  0x000055555555efae in ?? ()
#6  0x000055555555a5d1 in ?? ()
#7  0x00007ffff72a42b1 in __libc_start_main (main=0x55555555a230, argc=4, 
    argv=0x7fffffffe5f8, init=<optimized out>, fini=<optimized out>, 
    rtld_fini=<optimized out>, stack_end=0x7fffffffe5e8)
    at ../csu/libc-start.c:291
#8  0x000055555555a7ba in ?? ()

I operate dns.cmrg.net: Please feel free to test connections against
it :)


I have been able to reproduce the bug and have bisected the issue. It
was introduced in 3.5.3 with
commit 7e051ae28c288c218584f75dbc6c097a3b2564c9
Date:   Tue Jul 26 10:33:24 2016 +0200

    tools: TLS handling has been incorporated into socket_open()

    This is of particular usage to the server IP address loop, since
    we can detect fast open errors and retry handshake to the next IP

cu Andreas

`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

More information about the Gnutls-devel mailing list