On 11/12/2013 04:22 PM, Marc Glisse wrote:
On Tue, 12 Nov 2013, Ondřej Bílka wrote:
Anyway you need a better analysis to determine if user called realloc on
converted pointer.
Note that I am checking if the argument of free is the same as the
return value of malloc by looking at the SSA_NAME, not the C variable.
If the user called realloc on this value and then calls free on the same
value on all paths (including those where realloc returned a different
value), that's a broken program to start with. But indeed my current
patch fails on:
p=malloc(12);
q=realloc(p,16);
if(p==q)free(p);
exit(0);
because I (wrongly apparently) considered exit as safe as free :-(
Strictly speaking, this code is equivalent to:
p=malloc(12);
q=realloc(p,16);
free(p);
exit(0);
So I don't see how your optimization breaks it if it is applied to it. :)
p==q is undefined if the realloc call returned a different pointer.
Past-realloc pointer uses are fairly common, though, and often used to
adjust interior pointers. Empirically, this seem to work, although I
wouldn't be surprised if we already have optimizations which make
past-realloc pointer use undefined.
(I don't think C provides a safe way to update interior pointers in
place, FWIW.)
--
Florian Weimer / Red Hat Product Security Team
