A single NULL byte buffer overflow flaw was found in apr-util's apr_brigade_vprintf() function.

First let's assume the worst case and an attacker can control exactly what
is being sent to apr_brigade_vprintf and can trigger this issue by filling
the buckets just right so you end up with one that is perfectly full as
per the explanation at
http://www.mail-archive.com/dev@apr.apache.org/msg21592.html

     632 APU_DECLARE(apr_status_t) apr_brigade_vprintf(apr_bucket_brigade *b,
...
     638     struct brigade_vprintf_data_t vd;
     639     char buf[APR_BUCKET_BUFF_SIZE];
     640     apr_size_t written;
...
     656     *(vd.vbuff.curpos) = '\0';
...
     659     return apr_brigade_write(b, flush, ctx, buf, vd.vbuff.curpos -
buf);

If we get to line 656 with vd.vbuff.curpos pointing to one past the end of
buf we write a single NULL to the next thing on the stack after buf.  And
on the Linux x86 and x86_64 builds we looked at this is actually the first
byte of the vd structure, which is in fact the LSB of vd.vbuff.curpos
itself.

So the only use of this after the overwrite is on line 659 where
vd.vbuff.curpos gets used to calculate how much to write.  Before the
overwrite vd.vbuff.curpos was buf+APR_BUCKET_BUFF_SIZE (8000), but now it
could be between 0 and 255 bytes less.  So apr_brigade_write will end up
writing out between 0 and 255 bytes less than it ought to, causing the
truncation seen in the original bug report.

So for little endian systems it doesn't seem to have any security
consequence.  Of course for a big endian system apr_brigade_write could
end up dumping large amounts of memory (so an info disclosure leak or
crash).