Is converting int to size-t avoiding number overflow?

Question

I have read the following vulnerability report in grep and the associated commit in which all the integer and unsigned integer are replaced by size_t.

I have a simple question: is replacing unsigned integer by size_tavoiding number overflow (or other type of attack? If it is why? (In fact I don't see what it changes because I believed that the definition of size_t was typedef unsigned int size_t;).

Answer 1

size_t may be typedef'ed to unsigned int on your system but this may not be true on other systems, particularly embedded (non-X86) systems. By ANSI standard, unsigned int can me as small as 16 bits.

size_t is defined on each system to be guaranteed to be large enough to give the size of any possible object on that system.

In the case of this vulnerability, I'm guessing that (unsigned int) -> (size_t) was not actually part of the fix, at least on X86 systems, but part of an associated clean-up to guarantee that no problems remain.

It's also just good programming practice.

Answer 2

size_t is a type able to represent the size of any object in bytes: size_t is the type returned by the sizeof operator and is widely used in the standard library to represent sizes and counts.

Hence, size_t ia always able to represent the sizes correctly and never overflows in this sense.

Also, size_t may be bigger, equal or even smaller than an unsigned int and your compiler might make assumption about it for optimization purpose. So, size_t and unsigned int are different.

Answer 3

unsigned integer never overflows. It can't. Arithmetic on unsigned types is done using modular arithmetic. So no, replacing unsigned integer won't with size_t won't avoid any overflows, because there weren't any overflows to avoid in the first place with unsigned int.

In response to some comments, I mean "overflow" in the way the standard uses "overflow" when describing "integer overflow" as undefined behavior. For example, when the standard states "An example of undefined behavior is the behavior on integer overflow." it isn't suggesting that unsigned integers cause undefined behavior when the value can't fit inside the data type. Further, the standard says:

A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type

(section 6.2.5, paragraph 9)

Answer 4

A size_t can be larger (and it is on most 64 bit machines) than an int, and a size_t is the correct type to represent sizes/lengths.

The patch changes unsigned int to size_t to avoid possible problems where more memory is available than can be stored in an unsigned int, as well as an int. Both which would wrap/overflow if enough memory was available. though wrapping an int may give you negative results, with more fatal(crash prone) consequences than wrapping an unsigned it.

So it seems that the real problem was wrapping an int around, giving you negative results, making it possible to index memory outside what should be possible - fixing that to just use an unsigned int - you may as well change it all to use the more correct size_t.