integer overflow yields incorrect results and buffer overflow on 64-bit machines

[Torbjorn Granlund]

Vincent Lefevre <vincent at vinc17.org> writes:

  The fact that GMP does not define any exception processing (in the
  sense, just abort in case implementation or system limits are reached)
  was known to me, but not the fact that GMP could yield incorrect
  results and behave erratically just because some internal limits
  (unknown to the user) are reached.
  
Every day brings some new enlightenment!  :-)

  > Reporting it as a bug, in particular to Debian, is utterly
  > pointless, and I am sure you are fully aware of that.
  
  Well, at least the bug is recorded somewhere.

You ought to record bugs for mpz_add and mpz_mul, and mpz_sub and ...
too, since they can also yield 16 Gibyte results and overflow and
cause major havoc.  :-)
  
  > One might say that the slogan "Arithmetic without limtations" no
  > longer holds, since some big tin 64-bit machines could perhaps have
  > enough memory to make this GMP limitation reachable.  But we're
  > talking of more than 128 Gibyte memory here.
  
  Note that's 16 GB here (but see below).
  
Sure, I did the maths wrong.  That's more reachable than 128 Gibyte,
for sure.

  Now, concerning this bug, I think that a test in _mpz_realloc and
  mpz_realloc2 would be sufficient (note that INT_MIN should be
  forbidden too as the code sometimes take the opposite).

That might be possible, and that would mean zero cost.

  [*] To give an example, GMP can be used in PHP. In some contexts, the
  webmaster may choose not to set any computational limit (e.g. in case
  of a dedicated server). So, DoS could be accepted, but letting a way
  to hijack the server would be unacceptable.

If somebody allows arbitrary argument to arbitrary GMP functions from
PHP, then yes.  But that does not seem like a realistic scenario.

-- 
Torbjörn