https://bugs.exim.org/show_bug.cgi?id=2251
Bug ID: 2251
Summary: Segfault when LDAP lookup does not return a result
Product: Exim
Version: 4.90
Hardware: x86
OS: Linux
Status: NEW
Severity: bug
Priority: medium
Component: Lookups
Assignee: nigel@???
Reporter: x.meaden@???
CC: exim-dev@???
Created attachment 1074
-->
https://bugs.exim.org/attachment.cgi?id=1074&action=edit
Patch used to resolve issue
We've updated to the EPEL shipped 4.90.1 (exim-4.90.1-2.el7.x86_64) from
exim-4.89-4.el7.x86_64 and have started seeing frequent segfaults.
Mar 8 12:26:59 americano kernel: exim[1607]: segfault at 8 ip 0000560dd32915d0
sp 00007fffcef352b0 error 4 in exim[560dd31b1000+133000]
Stoking up gdb for live coredump shows:
Core was generated by `exim -bd -d+all'.
Program terminated with signal 11, Segmentation fault.
#0 0x0000560dd32915d0 in perform_ldap_search (ldap_url=<optimized out>,
server=<optimized out>, server@entry=0x7fffcef354a0 "localhost",
s_port=<optimized out>, search_type=search_type@entry=1,
res=res@entry=0x7fffcef35720, errmsg=errmsg@entry=0x560dd34fa778
<search_error_message>, defer_break=defer_break@entry=0x7fffcef35488,
user=user@entry=0x560dd48f4810 "uid=<removed>",
password=password@entry=0x560dd48f4840 "<removed>",
sizelimit=sizelimit@entry=0, timelimit=timelimit@entry=0,
tcplimit=tcplimit@entry=0, dereference=dereference@entry=0,
referrals=referrals@entry=0x7f6b07d321e0 <ber_pvt_opt_on>) at ldap.c:1076
1076 DEBUG(D_lookup) debug_printf("LDAP search: returning: %s\n", data->s);
We can reliably reproduce the segfault using "exim -bt <address>" too.
This line appears to have changed between the two versions:
@@ -1077,8 +1073,8 @@ if (!attribute_found)
/* Otherwise, it's all worked */
-DEBUG(D_lookup) debug_printf("LDAP search: returning: %s\n", data);
-*res = data;
+DEBUG(D_lookup) debug_printf("LDAP search: returning: %s\n", data->s);
+*res = data->s;
RETURN_OK:
if (result != NULL) ldap_msgfree(result);
The other references to data in ldap.c seem to be wrapped in if(data) but not
this one...
(gdb) print data
$1 = (gstring *) 0x0
This is the configuration (in the rewrite part of the config) that triggers
this bug:
# Convert short forms to longforms for staff
*@kent.ac.uk "${lookup ldap {user=\"<%= @ldapUserDN %>\" pass=\"<%= @ldapPasswd
%>\"
ldap:///o=kent.ac.uk,o=uni?unikentmailid?sub?(&(objectClass=mailRecipient)(!(inetUserStatus=deleted))(mailAlternateAddress=smtp:${quote_ldap:${local_part}@${domain}})(!(&(unikentmailOptinActive=*)(!(unikentmailOptinChoice=*)))))}{$value}fail}@???"
bcsfrtFT
(It is expected that no result will be retrieved for "unikentmailid" for most
of our email addresses, and this has been functioning fine for over a year.)
We have applied the attached patch to the EPEL version of the source and it has
been functioning as expected for the last twelve hours.
--
You are receiving this mail because:
You are on the CC list for the bug.
