Why is ring crashing in gnutls in Jessie?
Petter Reinholdtsen
pere at hungry.com
Mon Aug 29 10:46:03 UTC 2016
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
More information about the Pkg-gnutls-maint
mailing list