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