Re: malloc canary corruption

[Ingo Schwarze <schwarze@usta.de>]

Hi Anthony,

Anthony J. Bentley wrote on Tue, Feb 12, 2019 at 10:45:16PM -0700:

> I noticed rancid's par(1) caused mandoc to crash.
> 
> $ sysctl vm.malloc_conf
> vm.malloc_conf=C
> $ cat example # note the blank line
> .P
> .El
> .El
> 
> $ mandoc example
> mandoc(90888) in free(): chunk canary corrupted 0xb73c1ad12f0 0x1@0x1
> Abort trap (core dumped)

Fixed with the commit below.

In case of an empty input line, control flow exits the inner while(i)
loop early, never reaching the ln.sz / resize_buf() check inside
the loop.  The simplest and most robust fix is to also do the ln.sz
check at the other place writing to the buffer, outside the inner
loop.

Thanks for reporting and sorry for the delay caused by overlooking
these two bug reports.

Yours,
  Ingo


Log Message:
-----------
When the last line of the input is empty and the previous line reduced
the line input buffer to a length of one byte, do not write one byte 
past the end of the line input buffer.  Minimal code to show the bug:
printf ".ds X\n.X\n\n" | MALLOC_OPTIONS=C mandoc
Bug found by bentley@ in the sysutils/rancid par(1) manual page.

Modified Files:
--------------
    mandoc:
        read.c

Revision Data
-------------
Index: read.c
===================================================================
RCS file: /home/cvs/mandoc/mandoc/read.c,v
retrieving revision 1.211
retrieving revision 1.212
diff -Lread.c -Lread.c -u -p -r1.211 -r1.212
--- read.c
+++ read.c
@@ -255,6 +255,8 @@ mparse_buf_r(struct mparse *curp, struct
 		/* XXX Ugly hack to mark the end of the input. */
 
 		if (i == blk.sz || blk.buf[i] == '\0') {
+			if (pos + 2 > ln.sz)
+				resize_buf(&ln, 256);
 			ln.buf[pos++] = '\n';
 			ln.buf[pos] = '\0';
 		}
--
 To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv