lmtpd segfaults after update to 2.4.19, seems it wants to act as proxy

[ellie timoney]

On Wed, May 24, 2017, at 05:57 PM, Don Lewis wrote:
> On 24 May, ellie timoney wrote:
> > On Wed, May 24, 2017, at 04:17 PM, Don Lewis wrote:
> >> This first version of the patch worked for me.  A problem with
> >> 
> >> the second version of the patch is that mlookup() gets called in
> >> 
> >> a bunch of different places and the server variable would need
> >> 
> >> to be initialized in all of them.  In verify_user(), mlookup is called
> >> 
> >> several times, so server would have to be set to NULL before
> >> 
> >> each call.
> >> 
> >> 
> > 
> > Oh, good catch, I didn't look for other occurrences.  
> > 
> > Attached is an updated version of my patch that initialises these
> > variables correctly.
> 
> I mentioned verify_user() because of this particular section of code:
> 
>         r = mlookup(namebuf, &server, &acl, NULL);
> 
>         if (r == IMAP_MAILBOX_NONEXISTENT && !user &&
>             config_getswitch(IMAPOPT_LMTP_FUZZY_MAILBOX_MATCH) &&
>             /* see if we have a mailbox whose name is close */
>             fuzzy_match(namebuf)) {
> 
>             /* We are guaranteed that the mailbox returned by
>             fuzzy_match()
>                will be no longer than the original, so we can copy over
>                the existing mailbox.  The keeps us from having to do the
>                fuzzy match multiple times. */
>             strcpy(mailbox, domain ? namebuf+strlen(domain)+1 : namebuf);
> 
>             r = mlookup(namebuf, &server, &acl, NULL);
>         }
> 
> Could the first mlookup() call set server and the second call to
> mlookup() not touch it?  If so, what should the final value of server
> be, the result of the first mlookup() call, or should it be NULL?  If
> the latter, then we would need to explicitly assign NULL to server
> before the second call.  I don't understand the code well enough to say.
> 

Nah, the way mlookup() is now, it only sets server or acl if it succeeds
(in which case it returns 0).  If it returns a failure (r != 0), then
server/acl will be untouched.  Since the second call is conditional on r
being a specific (non-zero) value, we only reach the second call in
cases where we know server and acl haven't already been set by the
earlier one (i.e. they're both known to still be NULL).

Cheers,

ellie