gmp-4.1.2 integer overflow
Jason
jasonmoxham at btclick.com
Sat Feb 14 22:48:57 CET 2004
On Saturday 14 Feb 2004 10:14 pm, Kevin Ryde wrote:
> Jason <jasonmoxham at btclick.com> writes:
> > line 66 in mpz/root.c
> >
> > unb = un * GMP_NUMB_BITS - cnt + GMP_NAIL_BITS;
>
> That's changed in the development sources, is it still a problem
> there?
no
>
> We're probably not overly worried about cases where an mpz of more
> than LONG_MAX or ULONG_MAX bits induces an overflow. Most systems
> usually won't have enough address space or enough memory to actually
> hold one of those. Though if there's an easy change that can remove
> any limit it can be considered.
I did a quick correction for the above line , and ran an example that would of
had integer overflow in the existing code , its still runing after 3
hours ...
So its possible to get this high with a cheap PC(32 bit) 1GB RAM
Quote from gmp home-page
"There is no practical limit to the precision except the ones implied by the
available memory in the machine GMP runs on. "
Perhaps a definition of "practical limit"
Please excuse my ignorance on this point but doesn't integer overflow of a
buffer size calculation create a buffer overflow and therefore a possible
security risk ?
More information about the gmp-bugs
mailing list