Why is ring crashing in gnutls in Jessie?

[Petter Reinholdtsen]

Hi

Not sure if this is a good place to ask, but I am running short on ideas
and decided to give it a go.

I'm trying to backport ring.cx to Debian Jessie from unstable, and it
crashes in gnutls.  Details can be found in
<URL: https://bugs.debian.org/830265 >.  According to gdb it crashes one
place, while valgrind report the location elsewhere.

This is the gdb backtrace:

(gdb) bt
#0  __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:36
#1  0x00007ffff5f0731f in memcpy (__len=32767, __src=0x7fffffffc35c, __dest=0x7fffffffc40c)
    at /usr/include/x86_64-linux-gnu/bits/string3.h:51
#2  x86_sha1_update (ctx=0x7fffffffc3f0, length=<optimized out>, data=0x555555b8bb46 "")
    at sha-x86-ssse3.c:126
#3  0x00007ffff5f07757 in wrap_x86_hash_fast (algo=<optimized out>, text=0x555555b8b920, 
    text_size=550, digest=0x7fffffffc640) at sha-x86-ssse3.c:339
#4  0x00007ffff5e7eb26 in _gnutls_hash_fast (algorithm=algorithm at entry=GNUTLS_DIG_SHA1, 
    text=0x555555b8b920, textlen=550, digest=digest at entry=0x7fffffffc640)
    at gnutls_hash_int.c:114
#5  0x00007ffff5ed6528 in _gnutls_get_key_id (pk=pk at entry=GNUTLS_PK_RSA, 
    params=params at entry=0x7fffffffc550, output_data=output_data at entry=0x7fffffffc640 "", 
    output_data_size=output_data_size at entry=0x7fffffffc638) at x509.c:2523
#6  0x00007ffff5ed6680 in gnutls_x509_crt_get_key_id (crt=0x555555b7d0b0, 
    flags=<optimized out>, output_data=0x7fffffffc640 "", output_data_size=0x7fffffffc638)
    at x509.c:2583
#7  0x00005555557a4179 in dht::crypto::Certificate::getId (this=this at entry=0x7fffffffc7a0)
    at crypto.cpp:627
#8  0x00005555555fc928 in ring::RingAccount::loadIdentity (this=this at entry=0x555555b35300)
    at ringaccount.cpp:508
#9  0x00005555555fdccd in ring::RingAccount::checkIdentityPath (this=0x555555b35300)
    at ringaccount.cpp:452
#10 0x000055555565232f in ring::Manager::loadAccount (
    this=this at entry=0x555555aef300 <ring::Manager::instance()::instance_>, node=..., 
---Type <return> to continue, or q <return> to quit---q
errorCount=@Quit
(gdb)

And this is the valgrind crash (after several other non-fatal valgrind
issues):

==28650== Process terminating with default action of signal 11 (SIGSEGV)
==28650==  Access not within mapped region at address 0xEB084C0D
==28650==    at 0x4C2D7D1: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:915)
==28650==    by 0x6B6D31E: x86_sha1_update (in /usr/lib/x86_64-linux-gnu/libgnutls-deb0.so.28.41.0)
==28650==    by 0x6B6D756: wrap_x86_hash_fast (in /usr/lib/x86_64-linux-gnu/libgnutls-deb0.so.28.41.0)
==28650==    by 0x6AE4B25: _gnutls_hash_fast (in /usr/lib/x86_64-linux-gnu/libgnutls-deb0.so.28.41.0)
==28650==    by 0x6AF182B: gnutls_fingerprint (in /usr/lib/x86_64-linux-gnu/libgnutls-deb0.so.28.41.0)
==28650==    by 0x351627: dht::InfoHash::get(unsigned char const*, unsigned long) (infohash.cpp:57)
==28650==    by 0x1B989C: get (infohash.h:185)
==28650==    by 0x1B989C: ring::RingAccount::doRegister_() (ringaccount.cpp:884)
==28650==    by 0x9AC396F: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.20)
==28650==    by 0x6DD30A3: start_thread (pthread_create.c:309)
==28650==    by 0xA31787C: clone (clone.S:111)

The program work work in unstable, so something relevant must have
changed between Jessie and unstable.  As this is a crash bug, I worry
that this is some security issue still affecting Jessie.

Do you have any ideas how to debug this?  Any ideas what could be the
problem?

-- 
Happy hacking
Petter Reinholdtsen