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: jgh146exb@wizmail.org
Reporter: gedalya@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/ ##
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: jgh146exb@wizmail.org
Reporter: gedalya@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/ ##