Bug#1004740: exim4: SIGSEGV (maybe attempt to write to immutable memory) when sending a mail; message frozen

[Vincent Lefevre]

On 2022-02-03 14:21:58 +0100, Marc Haber wrote:
> Is the bug repeatable by unfreezing the message and forcing a delivery
> attempt? If so, you might be able to get a core dump from the delivering
> exim.

The delivery was successful. There was still a "TLS error on
connection (recv): The TLS connection was non-properly terminated."
error, but no 450:

2022-02-02 13:42:28 Start queue run: pid=150965 -qff
2022-02-02 13:42:28 1nEt2b-0008jG-97 Unfrozen by forced delivery
2022-02-02 13:42:31 1nEt2b-0008jG-97 H=mx1.mailchannels.net [54.189.39.249] TLS error on connection (recv): The TLS connection was non-properly terminated.
2022-02-02 13:42:31 1nEt2b-0008jG-97 => xxx at yyy R=dnslookup T=remote_smtp H=mx1.mailchannels.net [54.189.39.249] X=TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256 CV=yes DN="CN=*.mailchannels.net" C="250 2.0.0 Ok: queued as 6D9D5201EF"
2022-02-02 13:42:31 1nEt2b-0008jG-97 Completed
2022-02-02 13:42:31 End queue run: pid=150965 -qff

> If the 450 is casued by greylisting on the remote side, that debugging
> attempt must be close to the first time of sending the message so that
> the 450 is still there.

Unfortunately, I can't control that.

Perhaps the bug is due to the combination of both a "TLS error on
connection (recv): The TLS connection was non-properly terminated."
error and a 450, e.g. in case exim does something valid only if
there were no errors. A potential security issue?

If I understand correctly, the error comes from

  record_io_error(state, (int)inbytes, US"recv", NULL);

in src/tls-gnu.c, tls_read().

-- 
Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)