[exim-dev] [Bug 2251] New: Segfault when LDAP lookup does no…

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: admin
Ημερομηνία:  
Προς: exim-dev
Αντικείμενο: [exim-dev] [Bug 2251] New: Segfault when LDAP lookup does not return a result
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.