Why is ring crashing in gnutls in Jessie?

Petter Reinholdtsen pere at hungry.com
Mon Aug 29 10:46:03 UTC 2016


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

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

==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

Happy hacking
Petter Reinholdtsen

More information about the Pkg-gnutls-maint mailing list