(Again) Some trouble with dovecot 2.1(.7) and SASL

[Timo Sirainen]

On 13 Aug 2014, at 22:32, admin <admin at awib.it> wrote:

> The parentheses in the subject are due to referral to this discussion on the mailing list: http://dovecot.org/list/dovecot/2012-February/063851.html
> 
> At first I thought I found the problem, but then realized this was 2012 and the suggested patch already is applied in dovecot.
> 
> I also have segault messages in my kernel log; not too many, but it was enough to dig for it:
> 
>> Wed Jun 25 08:29:05 2014 auth[17590]: segfault at 10 ip 00007f02ad5e8e56 sp 00007fff932f9250 error 4 in auth[7f02ad5d3000+40000]
>> Mon Jun 30 16:11:41 2014 auth[12501]: segfault at 10 ip 00007fc6a1fefe56 sp 00007fff276e6ea0 error 4 in auth[7fc6a1fda000+40000]
>> Sat Jul  5 13:11:32 2014 auth[15603]: segfault at 10 ip 00007f6447a6be56 sp 00007fff09c48020 error 4 in auth[7f6447a56000+40000]
>> Tue Jul  8 05:08:21 2014 auth[30071]: segfault at 10 ip 00007ff22656ae56 sp 00007fff26b017f0 error 4 in auth[7ff226555000+40000]
>> Mon Jul 21 14:25:28 2014 auth[30918]: segfault at 10 ip 00007fe1fc817e56 sp 00007fff7e654f20 error 4 in auth[7fe1fc802000+40000] <---
>> Wed Aug 13 18:56:31 2014 auth[27593]: segfault at 10 ip 00007ffbf8ce8e56 sp 00007fffe0157f70 error 4 in auth[7ffbf8cd3000+40000]
>> Wed Aug 13 18:57:59 2014 auth[24264]: segfault at 10 ip 00007f2df31bde56 sp 00007fff094263c0 error 4 in auth[7f2df31a8000+40000]
> 
> 
> The last 2 entries are a result of me being able to reproduce the problem, the 3rd last is the only one I was able to track down (due to log rotation)

Having a gdb backtrace of the crash would be very useful. See http://dovecot.org/bugreport.html

> I tracked the problem down to a contact form of a website of one of my customers. whenever used, the segfault gets triggered.
> Nevertheless, the message always gets delivered.
> 
> So we are talking about the marked line; the corresponding log entries from mail.info:
> 
>> Jul 21 14:25:29 mail postfix/smtpd[27590]: D4D8E44752: client=unknown[<webserver ip>], sasl_method=CRAM-MD5, sasl_username=<existing account and working account>

Looks like some bug related to CRAM-MD5. I don't see any fixes to it since v2.1.7, but I looked through the code and I don't see any obvious bugs at least. It's also possible that the bug is elsewhere in auth and has been fixed since v2.1.7.