possible heap corruption in lmtpd

[brong]

From: Larry Greenfield Bugzilla-Id: 390 Version: 2.0.x Owner: leg+cyrus@andrew.cmu.edu

[brong]

From: Larry Greenfield

following crash found on mail1, backtrace included below. this looks like (most likely) a double free() problem, possible a scribbling out-of-bounds error. this looks like a bitch to debug without being able to reproduce it. it's also a more serious problem the longer we run lmtpd processes.

0 0xfee45d2c in realfree () from /usr/lib/libc.so.1

1 0xfee4660c in cleanfree () from /usr/lib/libc.so.1

2 0xfee45794 in _malloc_unlocked () from /usr/lib/libc.so.1

3 0xfee4568c in malloc () from /usr/lib/libc.so.1

4 0x46f90 in xstrdup (

str=0xffbee762 "<bounce-riddles-9208@riddlesandmore.net> BODY=8BITMIME")
at xmalloc.c:56

5 0x1acec in parseaddr (

s=0xffbee762 "<bounce-riddles-9208@riddlesandmore.net> BODY=8BITMIME")
at lmtpengine.c:456

6 0x1c7c8 in lmtpmode (func=0xdc240, pin=0xf3238, pout=0xf42a0, fd=-4266152)

at lmtpengine.c:1242

7 0x19ff8 in service_main (argc=1, argv=0xffbef904, envp=0xffbef90c)

at lmtpd.c:333

8 0x17a64 in main (argc=1, argv=0xffbef904, envp=0xffbef90c) at service.c:230

[brong]

From: Ken Murchison

possibly fixed in v1.26 of lmtpengine.c

[brong]

From: Larry Greenfield

i'm fairly confident that the majority of these cores i was seeing was due to illegal string manipulation in the sieve library.

lmtpd's header cache was being passed into libsieve, which would then change a pointer. lmtpd would later try to free this pointer, with the obvious disasterous results.