[exim-dev] [Bug 2915] New: SIGSEGV in ACL when message is se…

Pàgina inicial
Delete this message
Reply to this message
Autor: admin
Data:  
A: exim-dev
Assumpte: [exim-dev] [Bug 2915] New: SIGSEGV in ACL when message is second in that connection
https://bugs.exim.org/show_bug.cgi?id=2915

            Bug ID: 2915
           Summary: SIGSEGV in ACL when message is second in that
                    connection
           Product: Exim
           Version: 4.95
          Hardware: x86-64
                OS: Linux
            Status: NEW
          Severity: bug
          Priority: medium
         Component: ACLs
          Assignee: jgh146exb@???
          Reporter: graeme@???
                CC: exim-dev@???


Tricky to describe this one, so bear with me...

Running the EPEL packaged exim-4.95-1 on CentOS 7.

Very complex ACL in place to extract email addresses from the message body and
compare to a list of hashes in a file:

acl_mimeaddresses:
   warn set acl_m_lb_body = 
   warn condition = ${if match{$mime_content_type}{text}}
        mime_regex = \N(?s)([\w.+=-]+@\w[\w-]*\.[\w.-]+\w)\
                       (.+?([\w.+=-]+@\w[\w-]*\.[\w.-]+\w))?\
                       (.+?([\w.+=-]+@\w[\w-]*\.[\w.-]+\w))?\
                       (.+?([\w.+=-]+@\w[\w-]*\.[\w.-]+\w))?\
                       (.+?([\w.+=-]+@\w[\w-]*\.[\w.-]+\w))?\N
        condition = ${if forany{$regex1 :$regex3 :$regex5 :$regex7 :$regex9}\
                               {eq{${acl{acl_emailaddresses}{$item}}}{caught}}}
        log_message = LBORO-LB2: email address in body $acl_m_ea in LB:
$acl_m_LBdata \
                From: $header_From:, envelope-from $sender_address, \
                recipients=$recipients, Subject: $header_Subject:
        set acl_m_lb_body = 1
   accept


acl_emailaddresses:
   warn set acl_m_lbdata =
   accept condition = ${if eqi{$acl_arg1}{$sender_address}}
   accept condition = ${if eq{}\
        {${lookup dnsdb{defer_never,mxh=${domain:$acl_arg1}}}}}
          condition = ${if eq{}\
        {${lookup dnsdb{defer_never,a=${domain:$acl_arg1}}}}}


   warn   set acl_m_ea = ${sg{${lc:$acl_arg1}}{\\+.*@}{@}}
          condition    = ${if match{$acl_m_ea}{@g(oogle)?mail.com}}
          set acl_m_ea =
${sg{${local_part:$acl_m_ea}}{\\.}{}}@${domain:$acl_m_ea}


warn set acl_m_lbdata =
${lookup{${lc:${sha1:$acl_m_ea}}}lsearch{DPATH/lb-data.txt}}

warn log_message = LBORO-LB-DEBUG:
$acl_arg1/$acl_m_ea/${lc:${sha1:$acl_m_ea}}/$acl_m_lbdata

   accept condition = ${if !eq{}{$acl_m_lbdata}}
          message = caught


accept

The first then called from the MIME ACL:

## LB check 
    require acl = acl_mimeaddresses


When an email arrives over a TLS connection from the Internet, this runs
without issue. But for some hosts (yet to determine commonality) that send the
final period, wait for the 'accepted' and then reuse the same connection for
another message, the message flow stops at the 'require' clause with a SIGSEGV.

I've coerced Exim to dump core and collected a few (and then un-coerced it!)
and that gives a consistent backtrace like this:

(gdb) bt
#0  __strlen_sse2_pminub ()
    at ../sysdeps/x86_64/multiarch/strlen-sse2-pminub.S:38
#1  0x000055b5ccbe03a3 in expand_string_internal (
    string=0x55b5ceb54bb4 "$regex1 :$regex3 :$regex5 :$regex7
:$regex9}{eq{${acl{acl_emailaddresses}{$item}}}{caught}}}",
ket_ends=ket_ends@entry=1,
    left=left@entry=0x7ffea817dec8, skipping=0,
    honour_dollar=honour_dollar@entry=1,
    resetok_p=resetok_p@entry=0x7ffea817e2cc) at expand.c:8113
#2  0x000055b5ccbe91e8 in eval_condition (
    s=0x55b5ceb54bb4 "$regex1 :$regex3 :$regex5 :$regex7
:$regex9}{eq{${acl{acl_emailaddresses}{$item}}}{caught}}}",
    s@entry=0x55b5ceb54bad "forany{$regex1 :$regex3 :$regex5 :$regex7
:$regex9}{eq{${acl{acl_emailaddresses}{$item}}}{caught}}}",
    resetok=resetok@entry=0x7ffea817e2cc, yield=yield@entry=0x7ffea817e310)
    at expand.c:3302
#3  0x000055b5ccbe0c09 in expand_string_internal (
    string=0x55b5ceb54ba8 "${if forany{$regex1 :$regex3 :$regex5 :$regex7
:$regex9}{eq{${acl{acl_emailaddresses}{$item}}}{caught}}}",
    ket_ends=ket_ends@entry=0, left=left@entry=0x0, skipping=skipping@entry=0,
    honour_dollar=honour_dollar@entry=1, resetok_p=resetok_p@entry=0x0)
    at expand.c:4777
#4  0x000055b5ccbdf978 in expand_cstring (string=<optimized out>)
    at expand.c:8260
#5  0x000055b5ccbbecc1 in acl_check_internal (where=<optimized out>,
    addr=<optimized out>, s=<optimized out>, user_msgptr=<optimized out>,
    log_msgptr=<optimized out>) at acl.c:3022
#6  0x000055b5ccbbdadc in acl_check_internal (where=where@entry=3,
    addr=addr@entry=0x0, s=<optimized out>,
    user_msgptr=user_msgptr@entry=0x7ffea817f230, log_msgptr=<optimized out>)
    at acl.c:4427
#7  0x000055b5ccbc0a4f in acl_check (where=where@entry=3,
    recipient=recipient@entry=0x0, s=s@entry=0x55b5ceb48d50 "acl_check_mime",
    user_msgptr=user_msgptr@entry=0x7ffea817f230,
    log_msgptr=log_msgptr@entry=0x7ffea817f238) at acl.c:4539
#8  0x000055b5ccc58be9 in mime_acl_check (
    acl=acl@entry=0x55b5ceb48d50 "acl_check_mime", f=f@entry=0x55b5cee18710,
    context=context@entry=0x7ffea817f0f0,
    user_msgptr=user_msgptr@entry=0x7ffea817f230,
    log_msgptr=log_msgptr@entry=0x7ffea817f238) at mime.c:721
#9  0x000055b5ccc58cdf in mime_acl_check (
    acl=acl@entry=0x55b5ceb48d50 "acl_check_mime", f=f@entry=0x55b5cee18710,
    context=context@entry=0x0, user_msgptr=user_msgptr@entry=0x7ffea817f230,
    log_msgptr=log_msgptr@entry=0x7ffea817f238) at mime.c:744
#10 0x000055b5ccbb01a8 in run_mime_acl (acl=0x55b5ceb48d50 "acl_check_mime",
    smtp_yield_ptr=0x7ffea817f43c, smtp_reply_ptr=0x7ffea817f458,
    blackholed_by_ptr=0x7ffea817f448) at receive.c:1440
#11 0x000055b5ccc18fba in receive_msg (extract_recip=extract_recip@entry=0)
    at receive.c:3516
#12 0x000055b5ccbc4c7a in handle_smtp_call (accepted=0x7ffea817f750,
    accept_socket=<optimized out>, listen_socket_count=<optimized out>,
    listen_sockets=0x55b5ceb46294) at daemon.c:553
#13 daemon_go () at daemon.c:2594
#14 0x000055b5ccbb7667 in main (argc=3, cargv=0x7ffea81c0148) at exim.c:4947


I have a feeling at this point that the internals of the various expansions are
trying to access the memory that was allocated (and freed) by the first message
rather than the second. That's probably wrong though, but whatever it is - it
shouldn't be doing this!

Happy to provide more info if required.

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