segfault calling gcry_mpi_powm

Stef Bon stefbon at
Mon Jan 11 05:05:03 CET 2021


I'm still busy tracking this segfault.
I've compiled the latest git version of libgcrypt, installed in
/home/sbon/usr, add some debug flags,
and made sonssc link against it, and again the same segfault, but now
with more information:

coredump gdb gives oa:

(gdb) bt
#0  0x00007f6f1245d489 in  () at /lib64/
#1  0x00007f6f1294a9d5 in _gcry_free (p=0x7f6f0c001458) at global.c:1035
#2  0x00007f6f12a138bf in _gcry_mpi_free_limb_space (a=<optimized
out>, nlimbs=<optimized out>) at mpiutil.c:158
#3  0x00007f6f12a0feeb in _gcry_mpi_powm (res=0x7f6f0c00c5c8,
base=<optimized out>, expo=<optimized out>, mod=<optimized out>) at
#4  0x00007f6f12946db5 in gcry_mpi_powm (w=<optimized out>,
b=<optimized out>, e=<optimized out>, m=<optimized out>) at
#5  0x00005613647db46b in dh_create_local_key (k=0x7f6f11a5c6f0) at
#6  0x00005613647dc2b5 in start_diffiehellman_client
(connection=connection at entry=0x7f6f0c002340, k=k at entry=0x7f6f11a5c6f0,
H=H at entry=0x7f6f11a5c130)
   at ssh/keyexchange/key-exchange.c:390

Now something is getting more clear. Is it possible that the
_gcry_free function assumes it is dealing with secure memory?


More information about the Gcrypt-devel mailing list