[exim-dev] [Bug 1634] New: SMTP transport SEGV on DANE TLSA …

Pàgina inicial
Delete this message
Reply to this message
Autor: admin
Data:  
A: exim-dev
Assumpte: [exim-dev] [Bug 1634] New: SMTP transport SEGV on DANE TLSA SERVFAIL
https://bugs.exim.org/show_bug.cgi?id=1634

            Bug ID: 1634
           Summary: SMTP transport SEGV on DANE TLSA SERVFAIL
           Product: Exim
           Version: 4.85
          Hardware: x86
                OS: Linux
            Status: NEW
          Severity: bug
          Priority: medium
         Component: Delivery in general
          Assignee: nigel@???
          Reporter: wbreyha@???
                CC: exim-dev@???


I recently saw two SEGFAULTS on delivery to the domain loc.gov.

Both affected E-Mails had a single recipient.

I have configured my relay with 
  dnssec_request_domains  = *
  hosts_try_dane          = *
and I think this is the base for the segfault since both available MX hosts for
loc.gov, which are pps2b.loc.gov and pps2.loc.gov cause a SERVFAIL/timeout on
TLSA lookup for _25._tcp.<mxhost>.


exim -d showed....
------------------
set_process_info: 12483 delivering 1Yql28-0002Rm-6E to pps2.loc.gov
[140.147.249.134] (xxxx@???)
Connecting to pps2.loc.gov [140.147.249.134]:25 ... connected
140.147.249.134 in hosts_require_dane? no (option unset)
140.147.249.134 in hosts_try_dane? yes (matched "*")
DNS lookup of _25._tcp.pps2.loc.gov (TLSA) gave TRY_AGAIN
_25._tcp.pps2.loc.gov in dns_again_means_nonexist? no (option unset)
returning DNS_AGAIN
LOG: MAIN
H=pps2.loc.gov [140.147.249.134] Success
set_process_info: 12483 delivering 1Yql28-0002Rm-6E: just tried pps2.loc.gov
[140.147.249.134] for xxxx@???: result DEFER
...
and the same for the second host, but
...
pps2b.loc.gov [140.147.239.134] status = usable
140.147.239.134 in serialize_hosts? no (option unset)
delivering 1Yql28-0002Rm-6E to pps2b.loc.gov [140.147.239.134] (xxxx@???)
set_process_info: 12483 delivering 1Yql28-0002Rm-6E to pps2b.loc.gov
[140.147.239.134] (xxxx@???)
Connecting to pps2b.loc.gov [140.147.239.134]:25 ... connected
140.147.239.134 in hosts_require_dane? no (option unset)
140.147.239.134 in hosts_try_dane? yes (matched "*")
DNS lookup of _25._tcp.pps2b.loc.gov (TLSA) gave TRY_AGAIN
_25._tcp.pps2b.loc.gov in dns_again_means_nonexist? no (option unset)
returning DNS_AGAIN
reading pipe for subprocess 12483 (not ended)
read() yielded 0
remote delivery process 12483 ended: status=000b
set_process_info: 12481 delivering 1Yql28-0002Rm-6E
post-process xxxx@??? (1)
LOG: MAIN
== xxxx@??? R=external_delivery T=remote_smtp defer (-1): smtp transport
process returned non-zero status 0x000b: terminated by signal 11
------------

as far as I can tell from core/gdb bt the crash happens in
transports/smtp.c:smtp_transport_entry()

There
first_addr = prepare_addresses(addrlist, host);
is called which skips all addresses for which
addr->transport_return != DEFER
which is the case after the TRY_AGAIN from the first host. gdb says
addr->transport_return == PENDING_DEFER
for the recipient.

Back in smtp_transport_entry() some lines after first_addr ends up set to NULL
      if (rc == DEFER && first_addr->basic_errno != ERRNO_AUTHFAIL &&
                         first_addr->basic_errno != ERRNO_TLSFAILURE)
follows and causes the SIGSEGV.


--
You are receiving this mail because:
You are on the CC list for the bug.