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.
