However, calloc(ptr, nmemb, size) may have been called using smaller int variable types which would overflow when multiplied. Where if the variables storing the values passed to nmemb and size are less than or especially equal to their original values, I think it’d be good to state that:
freezero(ptr, (size_t)nmemb * (size_t)size); is guaranteed to work, but freezero(ptr, nmemb * size); does not have that guarantee. On Thu, Feb 18, 2021 at 3:42 AM Otto Moerbeek <o...@drijf.net> wrote: > On Wed, Feb 17, 2021 at 11:05:49AM -0700, Theo de Raadt wrote: > > > Luke Small <lukensm...@gmail.com> wrote: > > > > > I guess I always thought there'd be some more substantial overflow > mitigation. > > > > You have to free with the exact same size as allocation. > > Small correction: the size may be smaller than the original. In that > case, only a partial clear is guaranteed, the deallocation will still > be for the full allocation. Originally we were more strict, but iirc > that was causing to much headaches for some. See > https://cvsweb.openbsd.org/src/lib/libc/stdlib/malloc.c?rev=1.221 > > But the point stands: nmemb * size does not overflow, since the > original allocation would have overflowed and thus failed. > > -Otto > > > > > nmemb and size did not change. > > > > The math has already been checked, and regular codeflows will store the > > multiple in a single variable after successful checking&allocation, for > > reuse. > > > > > Would it be too much hand-holding to put in the manpage that to avoid > potential > > > freeezero() integer overflow, > > > it may be useful to run freezero() as freezero((size_t)nmemb * > (size_t)size); > > > > Wow, Those casts make it very clear you don't understand C, if you do > > that kind of stuff elsewhere you are introducing problems. > > > > Sorry no you are wrong. > > > -- -Luke
