Re: [PATCH] crypto: fix a few memleaks/undefined pointer dereferences

Hi,

> >now, those are the obviously broken cases -
> Thanks. I'll put the patch in the pipe for R17.

Thanks!

> >what I am wondering about is
> >whether it is correct that almost none of the OpenSSL calls in crypto are
> >being checked for memory allocation failures!?
> Not sure what you mean. Can you give an example.

For example, almost none of the bignum calls (BN_.*) are checked for error
returns, the OpensSSL documentation explicitly states that you always have
to check returns because it uses dynamic memory allocation and thus
allocation failures might occur. Looking around in the code, I also found a
call to HMAC_Init(), for example, which I'm pretty sure also uses dynamic
allocation (and in any case, the OpenSSL documentation shows that is has an
error return, even though the possible causes of failure are not listed),
and then there are all those <algorithm>_Init calls and the like, of which
I don't have a clue whether they do use dynamic allocation, but in any
case, the OpenSSL documentation shows they also have error returns, and
those generally don't seem to be checked either.

> >IIUC, OpenSSL is configured
> >to use enif_alloc(), which according to this ...
> >
> >http://www.erlang.org/doc/man/erl_nif.html#enif_alloc
> >
> >... will return NULL in case of an allocation failure. Now, is that there
> >just to confuse people because the function doesn't actually ever return in
> >case of an allocation failure, or is this really severely broken? Am I
> >missing something?
> enif_alloc calls erts_alloc_fnf where "fnf" stands for "Failure Not
> Fatal" which means that it will return NULL on failure.

IC - I didn't quite manage to penetrate all the allocator indirections,
though I didn't try too hard ;-)

Regards,  Florian
_______________________________________________
erlang-patches mailing list
[email protected]
http://erlang.org/mailman/listinfo/erlang-patches