From 25a87067860e0cb14ceb1066564aeac0b64ee789 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jan=20Pokorn=C3=BD?= Date: Tue, 1 Mar 2016 18:41:58 +0100 Subject: [PATCH] Fix segfault when memmoving with negative/enormous n MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/check_pack.c b/src/check_pack.c index 341cfb62..6aa903d7 100644 --- a/src/check_pack.c +++ b/src/check_pack.c @@ -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 */