Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 19 May 2014 17:44:59 +0200
From: Daniel Cegiełka <>
Subject: Re: thoughts on reallocarray, explicit_bzero?

2014-05-19 17:31 GMT+02:00 Isaac Dunham <>:
> Having read up on the LibreSSL fork of OpenSSL and also recently
> backported a nuber of libXfont CVE fixes for integer overflows,
> I've seen the risk posed by malloc(n*sizeof(x)) and realloc(ptr,
> n*sizeof(x)).
> calloc(n, sizeof(x)) can be used in place of malloc(n * sizeof(x)),
> but there's no standard function that does overflow checking for
> realloc(). OpenBSD has provided the extension reallocarray(), which
> provides for bounds checking like calloc() does.
> Additionally, there are times when a compiler will optimize away calls
> to bzero() on areas that are not used before free(); this can result in
> passwords getting left in memory. OpenBSD uses a wrapper function called
> explicit_bzero() to keep this from happening, thugh it seems to be possible
> to use some ugliness with volatile to stop it.
> Should musl provide reallocarray()?

In my opinion, yes, we should.

btw. no bzero()/bcopy() but memset() and memcpy() etc.


> And what's the best way to ensure that memory gets zeroed out?
> Thanks,
> Isaac Dunham

View attachment "explicit_bzero.diff" of type "text/plain" (796 bytes)

View attachment "reallocarray.diff" of type "text/plain" (1131 bytes)

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.