[Dovecot] segfault in dovecot imap 1.1.1 to 1.1.3
Dovecot dies with signal 11 (segfault) when doing some commands with a specific message
you'll find relevant information stored here: http://www.luria.ch/9e93676668e453b739ee3e085434e086/
the email: msg.anon.txt
input rawlog: 20081001-120137-24371.in
dovecot -n: dovecot-n.txt
the gdb backtrace: bt.txt
test system is running debian sarge, but same thing happens with debian etch (both x86) using xfs
always reproductible
Can you help me with this ?
(the problematic email is anonimized, tell-me if you need the originalone)
-- Rene Luria
- Rene Luria <operator@infomaniak.ch>:
(the problematic email is anonimized, tell-me if you need the originalone)
#3 0x080c86e6 in message_address_parse (pool=0x8139270, data=0x813d668 "undisclosed-recipients:;, Postkorb\" <BayernLB-Value-Advisory@bayernlb.de>il.net>",
That header looks fairly broken. But with all that real estate shit blowing up, who has the money for proper admins :)
-- Ralf Hildebrandt (Ralf.Hildebrandt@charite.de) snickebo@charite.de Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155 http://www.arschkrebs.de I'm looking for a job DUL helps enforce policy. If your toaster spoke TCP/IP would you want it sending e-mail to random third parties? If your answer is "yes" then I don't want any e-mail from any of your toasters -- Greg Woods
Ralf Hildebrandt a écrit :
(the problematic email is anonimized, tell-me if you need the originalone)
#3 0x080c86e6 in message_address_parse (pool=0x8139270, data=0x813d668 "undisclosed-recipients:;, Postkorb\" <BayernLB-Value-Advisory@bayernlb.de>il.net>",
That header looks fairly broken. But with all that real estate shit blowing up, who has the money for proper admins :)
No, avoid pasting only part of the trace.
#3 0x080c86e6 in message_address_parse (pool=0x8139270, data=0x813d668 "undisclosed-recipients:;, Postkorb\" <BayernLB-Value-Advisory@bayernlb.de>il.net>", size=24, max_addresses=4294967295, fill_missing=true) at message-address.c:310
look at the "size" argument
Ok, found the problem.
Here is a patch against 1.1.3 solving this issue
it comes from the "undisclosed-recipients:;" string and incrementing ctx->parser.data going after the end of the buffer
maybe there are other issues like this one because in many other
places in message-address.c the pointer gets incremented without
checking if it passes data.end
eventhough rfc822_skip_lwsp is called right after most of the time
Le 1 oct. 08 à 23:47, Rene Luria a écrit :
Here is a patch against 1.1.3 solving this issue
I forgot the link :) http://www.luria.ch/9e93676668e453b739ee3e085434e086/dovecot-lib-mail.diff
On Oct 2, 2008, at 1:01 AM, Rene Luria wrote:
Le 1 oct. 08 à 23:47, Rene Luria a écrit :
Here is a patch against 1.1.3 solving this issue
I forgot the link :) http://www.luria.ch/9e93676668e453b739ee3e085434e086/dovecot-lib-mail.diff
I actually did several error handling fixes to message-address.c that
are in v1.1 hg. Those should also fix this. I guess I should get
around to releasing 1.1.4..
participants (3)
-
Ralf Hildebrandt
-
Rene Luria
-
Timo Sirainen