On Sat, Sep 5, 2020 at 03:50:20PM +0200, Bernhard Übelacker wrote:
> Dear Maintainer,
> I tried to reproduce this fault, but did not get a segfault.
>
> However, I think the backtrace points to these lines:
>
> (gdb) bt
> #0 0x00007ffff769dbce in int_ctx_new () at ../crypto/evp/pmeth_lib.c:160
> #1 0x00007ffff769dcfa in EVP_PKEY_CTX_new () at
> ../crypto/evp/pmeth_lib.c:245
> #2 0x00007ffff7698d44 in do_sigver_init () at ../crypto/evp/m_sigver.c:29
> #3 0x00007ffff7698eab in EVP_DigestVerifyInit () at
> ../crypto/evp/m_sigver.c:97
> #4 0x00007ffff75bc7d2 in ASN1_item_verify () at
> ../crypto/asn1/a_verify.c:148
> #5 0x00007ffff7722490 in X509_verify () at ../crypto/x509/x_all.c:26
> ...
>
>
> https://sources.debian.org/src/openssl/1.1.1d-0+deb10u3/crypto/evp/pmeth_lib.c/#L160
>
> 159 if (pmeth->init) {
> 160 if (pmeth->init(ret) <= 0) {
> 161 ret->pmeth = NULL;
>
> As there is a check for pmeth->init being non-null, I guess
> it contains for some reason an invalid pointer.
>
>
> @Bruce Momjian,
> maybe you could install the following debug symbols packages
> `curl-dbgsym libcurl4-dbgsym libssl1.1-dbgsym` from the dbgsym
> repository described here:
>
> https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols
>
> Then run a new gdb session and when the segfault appears
> please run these commands in gdb:
> print pmeth->init
> bt full 5
Sure, here it is:
(gdb) run https://google.com
Starting program: /usr/bin/curl https://google.com
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff6730700 (LWP 30481)]
[Thread 0x7ffff6730700 (LWP 30481) exited]
Thread 1 "curl" received signal SIGSEGV, Segmentation fault.
0x00007ffff7679bce in int_ctx_new (pkey=pkey@entry=0x5555556035a0,
e=0x5555555bd8d0, e@entry=0x0, id=<optimized out>, id@entry=-1) at
../crypto/evp/pmeth_lib.c:160
160 ../crypto/evp/pmeth_lib.c: No such file or directory.
(gdb) print pmeth->init
$1 = (int (*)(EVP_PKEY_CTX *)) 0xf0e0d0c0b0a0908
(gdb) bt full 5
#0 0x00007ffff7679bce in int_ctx_new (pkey=pkey@entry=0x5555556035a0,
e=0x5555555bd8d0, e@entry=0x0, id=<optimized out>, id@entry=-1) at
../crypto/evp/pmeth_lib.c:160
ret = 0x555555609810
pmeth = 0x5555555eaaf0
#1 0x00007ffff7679cfa in EVP_PKEY_CTX_new
(pkey=pkey@entry=0x5555556035a0, e=e@entry=0x0) at ../crypto/evp/pmeth_lib.c:245
No locals.
#2 0x00007ffff7674d44 in do_sigver_init (ctx=ctx@entry=0x5555556034c0,
pctx=pctx@entry=0x0, type=type@entry=0x7ffff77b1fc0 <sha256_md>, e=e@entry=0x0,
pkey=pkey@entry=0x5555556035a0, ver=ver@entry=1)
at ../crypto/evp/m_sigver.c:29
No locals.
#3 0x00007ffff7674eab in EVP_DigestVerifyInit
(ctx=ctx@entry=0x5555556034c0, pctx=pctx@entry=0x0,
type=type@entry=0x7ffff77b1fc0 <sha256_md>, e=e@entry=0x0,
pkey=pkey@entry=0x5555556035a0)
at ../crypto/evp/m_sigver.c:97
No locals.
#4 0x00007ffff75987d2 in ASN1_item_verify (it=0x7ffff77c3e80
<X509_CINF_it>, a=a@entry=0x5555555ff698,
signature=signature@entry=0x5555555ff6a8, asn=asn@entry=0x5555555ff610,
pkey=0x5555556035a0)
at ../crypto/asn1/a_verify.c:148
type = 0x7ffff77b1fc0 <sha256_md>
ctx = 0x5555556034c0
buf_in = 0x0
ret = -1
inl = 0
mdnid = 672
pknid = 6
inll = 0
(More stack frames follow...)
I also got this output:
gdb) print *pmeth
$8 = {pkey_id = 50462976, flags = 117835012, init = 0xf0e0d0c0b0a0908,
copy = 0x1716151413121110, cleanup = 0x1f1e1d1c1b1a1918, paramgen_init =
0x98c476a19fc273a5, paramgen = 0x9cc072a593ce7fa9,
keygen_init = 0xdabe4402cda85116, keygen = 0xdeba4006c1a45d1a,
sign_init = 0x681bf10ff0df87ae, sign = 0x6715fc03fbd58ea6, verify_init =
0x924fa56f48f1e16d, verify = 0x8d51b87353ebf875,
verify_recover_init = 0x1799a7c97f8256c6, verify_recover =
0x8b59d56cec4c296f, signctx_init = 0xe7754752753ae23d, signctx =
0x39cf0754b49ebf27, verifyctx_init = 0x48097bc25f90dc0b,
verifyctx = 0x2f1c87c1a44552ad, encrypt_init = 0x87d3b21760a6f545,
encrypt = 0xa820a64334d0d30, decrypt_init = 0x54feb4be1cf7cf7c, decrypt =
0xdfa761d2f0bbe613, derive_init = 0x7929a8e7fefa1af0,
derive = 0x40e6afb34a64a5d7, ctrl = 0x2500f59b71fe4125, ctrl_str =
0xa1c725ad5bb1388, digestsign = 0xe04ff2a999665a4e, digestverify =
0xeacdf8cdaa2b577e, check = 0xe97909bfcc79fc24,
public_check = 0x36de686d3cc21a37, param_check = 0xd, digest_custom =
0x7ffff758ac80 <aesni_encrypt>}
(gdb) print pmeth->init[0]
Cannot access memory at address 0xf0e0d0c0b0a0908
(gdb) print *(pmeth->init)
Cannot access memory at address 0xf0e0d0c0b0a0908
(gdb) print *pkey
$2 = {type = 6, save_type = 6, references = 2, ameth = 0x7ffff77c09e0
<rsa_asn1_meths>, engine = 0x0, pmeth_engine = 0x0, pkey = {ptr =
0x5555556060f0, rsa = 0x5555556060f0, dsa = 0x5555556060f0,
dh = 0x5555556060f0, ec = 0x5555556060f0, ecx = 0x5555556060f0},
save_parameters = 1, attributes = 0x0, lock = 0x555555605f00}
(gdb) print *e
--> $3 = {id = 0x7ffff7fc9000 "pkcs11", name = 0x7ffff7fc9016 "pkcs11
engine", rsa_meth = 0x5555555bd170, dsa_meth = 0x0, dh_meth = 0x0, ec_meth =
0x5555555be4a0, rand_meth = 0x0, ciphers = 0x0, digests = 0x0,
pkey_meths = 0x7ffff7fc6800, pkey_asn1_meths = 0x0, destroy =
0x7ffff7fbebb0, init = 0x7ffff7fbeb80, finish = 0x7ffff7fbeb60, ctrl =
0x7ffff7fbeb10, load_privkey = 0x7ffff7fbea70, load_pubkey = 0x7ffff7fbead0,
load_ssl_client_cert = 0x0, cmd_defns = 0x7ffff7fcec80, flags = 0,
struct_ref = 8, funct_ref = 7, ex_data = {sk = 0x5555555bdac0}, prev =
0x5555555a95e0, next = 0x0}
I am using a pkcs11 hardware crypto device, and perhaps it is
misconfigured, but it probably shouldn't crash. This might be a library
bug, not sure. I will check the pkcs11's configuration now, but it used
to work.
--
Bruce Momjian <[email protected]> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
