Versions affected: latest cvs, 0.9.8*


zlib calloc and free callbacks are not initialized (zlib_statefull_init()
in crypto/comp/c_zlib.c) resulting in zlib using the default libc
functions. This is a problem especially for multi-process applications
that set some other mem. allocation functions via
CRYPTO_set_mem_functions() and expect them to be used (e.g. the
application set functions return memory allocated from a shared memory
pool). For such an application, allocating memory in a process and
trying to write/read from it from another process will most likely
produce a crash if the zlib mem. allocation functions are not changed.

Another problem is the intialization of zlib_stateful_ex_id in
 zlib_stateful_init(), for each ctx. Because zlib_stateful_ex_id is
  not shared, each time zlib_statefull_init() is called from a different
 process, a new different index will be generated.


This bug could have been already reported (workarrounds for it are used
 at least in ser for some time), but I couldn't find it in the tracker
 and it's not fixed yet, so here's a patch.

The patch sets zlib mem. alloc callbacks to some OPENSSL_malloc/free
based versions and moves zlib_stateful_ex_idx intialization in
COMP_zlib(), which is called during SSL_library_init() (via
SSL_COMP_get_compression_methods()). If SSL_librariy_init() is called
before forking openssl should work perfectly in multi-process
applications.
The patch is against a recent cvs snapshot (0.9.9-dev).

Patch url (in case the attachement is stripped by the tracker):
http://www.iptel.org/~andrei/openssl_patches/openssl_comp_zlib_malloc.patch


Andrei
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [email protected]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to