Possible bug in pipes.c

Hi procmail-dev,

I believe I've found a bug in pipes.c which causes procmail to malloc
massive amounts of memory on certain systems when piping mail through a
filter.

Since the patch is only one character, I will present it here in lieu of
any further description:

diff -rc procmail-3.22/src/pipes.c procmail-3.22-fixed/src/pipes.c
*** procmail-3.22/src/pipes.c   Tue Sep 11 00:58:44 2001
--- procmail-3.22-fixed/src/pipes.c     Wed Nov 21 23:53:39 2007
***************
*** 194,200 ****
       makeblock(&temp,Stdfilled);
       tmemmove(temp.p,Stdout,Stdfilled);
       readdyn(&temp,&Stdfilled,Stdfilled+backlen+1);
!      Stdout=realloc(Stdout,&Stdfilled+1);
       tmemmove(Stdout,temp.p,Stdfilled+1);
       freeblock(&temp);
       retStdout(Stdout,pwait&&pipw,!backblock);
--- 194,200 ----
       makeblock(&temp,Stdfilled);
       tmemmove(temp.p,Stdout,Stdfilled);
       readdyn(&temp,&Stdfilled,Stdfilled+backlen+1);
!      Stdout=realloc(Stdout,Stdfilled+1);
       tmemmove(Stdout,temp.p,Stdfilled+1);
       freeblock(&temp);
       retStdout(Stdout,pwait&&pipw,!backblock);

Even from the little context visible in the patch, it seems pretty clear
Stdfilled is intended as the length of a buffer, so removing the & is
the obvious fix.

Before the patch, procmail was trying to malloc about 2GB on my system
whenever I tried to use a filter in a recipe. (I'm running
Gentoo-hardened, with address space layout randomization, and &Stdfilled
was apparently ending up pretty high in memory.) With the patch it seems
to behave sanely, but I haven't started feeding my actual mail through
it yet.

Note that I think procmail frees the buffer somewhat later, so I don't
think this is a memory _leak_ -- it's just a temporary spike in usage,
which can be crippling when (as in my case) it's so large as to generate
OOM errors.

(I have reported this to [email protected], but so far no reply.)

Thanks for taking a look,
Glenn Willen