https://bugs.exim.org/show_bug.cgi?id=2886
Bug ID: 2886 Summary: Crashes in SMTP delivery attempt following a deferral Product: Exim Version: 4.96 Hardware: x86-64 OS: Linux Status: NEW Severity: bug Priority: medium Component: TLS Assignee: jgh146...@wizmail.org Reporter: geda...@gedalya.net CC: exim-dev@exim.org Created attachment 1414 --> https://bugs.exim.org/attachment.cgi?id=1414&action=edit exim4-daemon-light 4.96~RC0-1 Versions: 4.94 good, 4.9[56] bad. OS: Debian testing x86_64 TLS: gnutls 3.7.4-2, haven't tried OpenSSL This doesn't happen in an immediate delivery attempt or in "exim -M", but in a queue runner, if the first remote server responds with a deferral, exim crashes some time when talking to the next server. It can happen in tls_close() (after the message was successfully delivered, if the remote parry allows, or after getting a deferral): smtp_deliver -> tls_close -> gnutls_certificate_free_credentials -> gnutls_x509_trust_list_deinit, or it can be: smtp_deliver -> smtp_setup_conn -> tls_client_start -> verify_certificate -> gnutls_certificate_verify_peers2 -> gnutls_certificate_verify_peers -> _gnutls_x509_cert_verify_peers -> gnutls_x509_trust_list_verify_crt2 -> gnutls_x509_trust_list_get_issuer -> _gnutls_trust_list_get_issuer And on one occasion it crashed in arc_sign() (on an exim thus built) But long story short, it seems like exim would consistently crash, SIGFPE or SIGSEGV, during a subsequent delivery attempt after a deferral response. The real life circumstances are a gmail account over quota or a forwarded message graylisted by gmail or such. But I am reproducing this by simply configuring my own exim servers to defer. Attached is a log excerpt and backtrace from Debian's exim4-daemon-light 4.96~RC0-1 -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##