[exim] Segfaults with 4.95 (Re: Exim 4.95-RC2 released)

Pàgina inicial
Delete this message
Reply to this message
Autor: Evgeniy Berdnikov
Data:  
A: exim-users
Assumptes vells: Re: [exim] Exim 4.95-RC2 released
Assumpte: [exim] Segfaults with 4.95 (Re: Exim 4.95-RC2 released)
Hello.

Let me return to thread, discussed a month ago, when 4.95-RC2 was released.

Upgrading from 4.94-2 to 4.95-RC2 I got numerous segfaults on sender verify
callout, in _gnutls_trust_list_get_issuer() from libgnutls30 library,
and had to roll back to 4.92. The last mail on topic was from Jeremy:

On Wed, Sep 08, 2021 at 09:50:54AM +0100, Jeremy Harris via Exim-users wrote:
> On 08/09/2021 07:58, Evgeniy Berdnikov via Exim-users wrote:

[...]
> > Fault happens on sender verify callout, in rcpt or pre-data ACLs.
> > Here is the recent example, callout from acl_check_rcpt:
> >
> > Reading symbols from /usr/sbin/exim4...
> > [New LWP 1352271]
> > [Thread debugging using libthread_db enabled]
> > Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
> > Core was generated by `/usr/sbin/exim4 -bd -q1m'.
> > Program terminated with signal SIGSEGV, Segmentation fault.
> > #0  0xf7238b0d in _gnutls_trust_list_get_issuer (list=0x58441780,
> >      cert=0x59027530, issuer=0xffbec6a8, flags=0)
> >      at ../../../lib/x509/verify-high.c:1026

>
> Looking at a current GnuTLS tree, hopefully not too different to
> that used for your library version:
>
>    1012 int _gnutls_trust_list_get_issuer(gnutls_x509_trust_list_t list,
>    1013                                   gnutls_x509_crt_t cert,
>    1014                                   gnutls_x509_crt_t * issuer,
>    1015                                   unsigned int flags)
>    1016 {
>    1017         int ret;
>    1018         unsigned int i;
>    1019         size_t hash;
>    1020
>    1021         hash =
>    1022             hash_pjw_bare(cert->raw_issuer_dn.data,
>    1023                           cert->raw_issuer_dn.size);
>    1024         hash %= list->size;
>    1025
>    1026         for (i = 0; i < list->node[hash].trusted_ca_size; i++) {
>    1027                 ret =
>    1028                     gnutls_x509_crt_check_issuer(cert,
>    1029                                                  list->node[hash].
>    1030                                                  trusted_cas[i]);

>
> ... I'd say this is likely a problem internal to GnuTLS, not directly
> down to something exim passed it. You should involve the GnuTLS maintainers
> at this point (but please keep me in the loop).


Recently Exim-4.95 become available for Debian/testing, and I tried it,
keeping versions of packages libgnutls30 and libgnutls-dane0 (3.7.2-2).
The difference is impressive: for 4.94-2 there were no segfaults,
for 4.95-RC2 I got 134 core files in two days, for 4.95 I got only
one (!) core in two days. Segfault was in the same function.

But accidentally I catched that "list" in last core file is pointed not
to "struct gnutls_x509_trust_list_st", but to legal text string:

#0  0xf7291b0d in _gnutls_trust_list_get_issuer (list=0x57c945f0, cert=0x57c9f2b0, issuer=0xffb0b3c8, flags=0)
    at ../../../lib/x509/verify-high.c:1026
1026    ../../../lib/x509/verify-high.c: No such file or directory.
(gdb) p list
$1 = (gnutls_x509_trust_list_t) 0x57c945f0
(gdb) x/s list
0x57c945f0:     "validity"
(gdb)


Search for "validity" in binary files and sources of Exim and GnuTLS
shows that only one such string is in GnuTLS: lib/pkix_asn1_tab.c.

I studied previous 134 core files from 4.95-RC2, in most cases
"list" pointed to string, which is mentioned in lib/pkix_asn1_tab.c.
In particular, those strings pointed by "list" after crash

"algorithm" "notBefore" "serialNumber" "rdnSequence" "tbsCertificate"
"utcTime" "?1"

are present in GnuTLS sources and are absent in Exim source code.

I also looked through arguments of upper libgnutls30 entry point
before segfault: gnutls_certificate_verify_peers2(session,status).
The "session" is a huge structure, but it does not look as corrupted:
some well-named elements have reasonable values. So Jeremy's suggestion
that problem is in GnuTLS library looks reasonable.

One additional notice. I counted numbers of those specific for libgnutls
strings in last core file:

# for s in "validity" "algorithm" "notBefore" "serialNumber" "rdnSequence" "tbsCertificate" "utcTime" ; do echo -n "$s: " ; strings core.1400692 | grep -c "^$s\$" ; done
validity: 634
algorithm: 3661
notBefore: 633
serialNumber: 524
rdnSequence: 1269
tbsCertificate: 518
utcTime: 1019

High multiplication of memory structures looks strange, notably they are
rarely used ASN1 names... It may be indication of memory leakage, IMHO.

Any other ideas, what else can be inspected with this coredump?
--
Eugene Berdnikov