Your message dated Mon, 17 Oct 2011 09:19:17 +0200 with message-id <[email protected]> and subject line Re: Bug#467463: bug disposition has caused the Debian Bug report #467463, regarding libgmp3c2: integer overflow yields incorrect results and buffer overflow on 64-bit machines to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 467463: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467463 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: libgmp3c2 Version: 2:4.2.1+dfsg-4 Severity: important GMP doesn't check for integer overflows internally. In particular, the number of limbs is stored in an int (32 bits under Linux), which isn't sufficient, and the testcase below shows that one can get incorrect results. What occurs is that the correct number of limbs is allocated, but an incorrect (lower) value is stored and the current size _mp_size is incorrect too. With the test below, the _mp_size field becomes negative due to the integer overflow, which means a negative number (instead of positive): sign(2^c) = -1. Moreover what appears to be the most significant limb is no longer non-zero, so that one can get erratic behavior, e.g. buffer overflow (at least when reading, as shown in the testcase, and probably worse with user-defined alloc functions, because *__gmp_reallocate_func would be call with an incorrect old_size value). $ gcc -Wall -O2 gmp_powof2.c -o gmp_powof2 -lgmp $ ./gmp_powof2 0x2000000000 sizeof(mp_size_t) = 8 sizeof(n->_mp_alloc) = 4 sizeof(n->_mp_size) = 4 c = 137438953472 = 0x2000000000 bits n->_mp_alloc = -2147483646 = 0x80000002 limbs n->_mp_size = -2147483647 = 0x80000001 limbs sign(2^c) = -1 d = 137438953344 = 0x1fffffff80 bits p->_mp_alloc = 1 = 0x1 limbs p->_mp_size = 1 = 0x1 limbs popcount(p) = 0 Divisibility test... zsh: floating point exception (core dumped) ./gmp_powof2 0x2000000000 ------------------------------------------------------------------------ #include <stdio.h> #include <stdlib.h> #include <gmp.h> int main (int argc, char **argv) { mpz_t n, p; unsigned long c, d; if (argc != 2) { fprintf (stderr, "Usage: gmp_powof2 <count>\n"); exit (1); } printf ("sizeof(mp_size_t) = %d\n", (int) sizeof(mp_size_t)); printf ("sizeof(n->_mp_alloc) = %d\n", (int) sizeof(n->_mp_alloc)); printf ("sizeof(n->_mp_size) = %d\n", (int) sizeof(n->_mp_size)); c = strtoul (argv[1], NULL, 0); printf ("c = %lu = 0x%lx bits\n", c, c); mpz_init_set_si (n, 1); mpz_mul_2exp (n, n, c); printf ("n->_mp_alloc = %d = 0x%x limbs\n", n->_mp_alloc, (unsigned int) n->_mp_alloc); printf ("n->_mp_size = %d = 0x%x limbs\n", n->_mp_size, (unsigned int) n->_mp_size); printf ("sign(2^c) = %d\n", mpz_sgn (n)); d = 64 * ((unsigned long) - n->_mp_size - 1); printf ("d = %lu = 0x%lx bits\n", d, d); mpz_init (p); mpz_tdiv_q_2exp (p, n, d); mpz_abs (p, p); printf ("p->_mp_alloc = %d = 0x%x limbs\n", p->_mp_alloc, (unsigned int) p->_mp_alloc); printf ("p->_mp_size = %d = 0x%x limbs\n", p->_mp_size, (unsigned int) p->_mp_size); printf ("popcount(p) = %lu\n", mpz_popcount (p)); /* p can have a single limb 0. */ printf ("Divisibility test...\n"); printf ("mpz_divisible_p (p, p) = %d\n", mpz_divisible_p (p, p)); mpz_clear (p); return 0; } ------------------------------------------------------------------------ -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.23.16-server-amd64 Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1) Versions of packages libgmp3c2 depends on: ii libc6 2.3.6.ds1-13etch5 GNU C Library: Shared libraries libgmp3c2 recommends no packages. -- no debconf information
--- End Message ---
--- Begin Message ---Version: 2:4.2.3+dfsg-1 On 2011-10-16 18:22:26 -0500, Steve M. Robbins wrote: > You reported this bug in gmp v 4.2.1 some years ago. It is an > upstream bug and there was some discussion on the GMP list [1]. > > Do you know whether the bug still exists in gmp 5? What do you > want to do with this Debian bug report? On i686 and x86_64 machines, I get: gmp: overflow in mpz type i.e. the detection is done by GMP and one no longer gets an erratic behavior. According to GMP's NEWS file, this was fixed in GMP 4.2.3: Features: * The allocation functions now detect overflow of the mpz_t type. This means that overflow will now cause an abort, except when the allocation computation itself overflows. (Such overflow can probably only happen in powering functions; we will detect powering overflow in the future.) So, I'm closing this bug. -- Vincent Lefèvre <[email protected]> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
--- End Message ---
