]> granicus.if.org Git - check/commitdiff
Fix segfault when memmoving with negative/enormous n
authorJan Pokorný <jpokorny@redhat.com>
Tue, 1 Mar 2016 17:41:58 +0000 (18:41 +0100)
committerJan Pokorný <jpokorny@redhat.com>
Tue, 1 Mar 2016 19:30:01 +0000 (20:30 +0100)
I observed a segmentation fault caused by trying to memmove by -15,
which makes 18446744073709551601 on my 64-bit platform after an argument
type promotion (from int into size_t).  In my case, this was connected
with filling up disk during the test facilitated by check, hence I derive
that the main issue was that not enough bytes for particular type of
message was actually read (and previously written, for that matter) and
because of this incompleteness, get_result happily consumed more bytes
than was read.

Additional debugging info at the point of segfault (src/check_pack.c):

> 468│         /* Move remaining data in buffer to the beginning */
> 469├>        memmove(buf, buf + n, nparse);
> 470│         /* If EOF has not been seen */
> 471│         if(nread > 0)
>
> (gdb) p nparse
> $1 = -15
> (gdb) p n
> $2 = 23
> (gdb) p nread
> $3 = 0

src/check_pack.c

index 341cfb6221eb6a8d4d314a01ae2a963bc9842e57..6aa903d747d05e22c5cdc47a6862ff779e812070 100644 (file)
@@ -465,6 +465,8 @@ RcvMsg *punpack(FILE * fdes)
         /* Parse one message */
         n = get_result(buf, rmsg);
         nparse -= n;
+        if (nparse < 0)
+            eprintf("Error in call to get_result", __FILE__, __LINE__ - 3);
         /* Move remaining data in buffer to the beginning */
         memmove(buf, buf + n, nparse);
         /* If EOF has not been seen */