On Fri, May 21, 2010, Sander Temme wrote:
> Folks,
>
> I have been working for several days to track down an issue where Apache
> segfault on startup, most of the time, but ONLY on Red Hat and ONLY when the
> CHIL engine is enabled.
>
> I'm working with OpenSSL, Apache and APR HEAD on an up-to-date CentOS 5.4
> 32bits.
>
> The segfault occurs when a stale free_func function pointer is called at
> crypto/ex_data.c:522
>
> for(i = 0; i < mx; i++) { if(storage[i] && storage[i]->free_func) { ptr
> =
> CRYPTO_get_ex_data(ad,i); -->
> storage[i]->free_func(obj,ptr,ad,i, storage[i]->argl,storage[i]->argp);
> }
> }
>
> as we're trying to free an RSA structure. Setting a breakpoint on that line
> shows that the first few times this gets called, there is one on the stack:
>
> Breakpoint 1, int_free_ex_data (class_index=6, obj=0xb6535fa8,
> ad=0xb6535fd8) at ex_data.c:522 522 storage[i]->free_func(obj,ptr,ad,i,
> (gdb) p class_index $15 = 6 (gdb) p sk_num(def_get_class(6)->meth) $16 = 1
> (gdb) p *(CRYPTO_EX_DATA_FUNCS *)sk_value(def_get_class(6)->meth,0) $17 =
> {argl = 0, argp = 0x2abac8, new_func = 0, free_func = 0x2aaee7
> <hwcrhk_ex_free>, dup_func = 0}
>
> However, the second time through Apache's configuration processing sequence,
> a second CRYPTO_EX_DATA_FUNCS structure has appeared:
>
> Breakpoint 1, int_free_ex_data (class_index=6, obj=0xb6801fa8,
> ad=0xb6801fd8) at ex_data.c:522 522 storage[i]->free_func(obj,ptr,ad,i,
> (gdb) p class_index $41 = 6 (gdb) p sk_num(def_get_class(6)->meth) $42 = 2
> (gdb) p *(CRYPTO_EX_DATA_FUNCS *)sk_value(def_get_class(6)->meth,0) $43 =
> {argl = 0, argp = 0x2abac8, new_func = 0, free_func = 0x2aaee7, dup_func =
> 0} (gdb) p *(CRYPTO_EX_DATA_FUNCS *)sk_value(def_get_class(6)->meth,1) $44 =
> {argl = 0, argp = 0x7e0ac8, new_func = 0, free_func = 0x7dfee7
> <hwcrhk_ex_free>, dup_func = 0}
>
> As you can see the first entry still points to the old location of
> hwcrhk_ex_free, which is now stale. It seems that, of operating systems,
> only Red Hat is likely to load a library (the vendor-supplied Hardware
> Crypto Hook Library libnfhwcrhk.so) in a different memory location the
> second time around, which is why this issue has escaped attention so far.
>
> My question is where should this get fixed? We can prevent Apache from
> loading the Engine twice, which is a spot band-aid. And Apache's double
> pass through the config file (and calling its post_config hook handlers) is
> not going away any time soon. I would rather fix this by having the CHIL
> Engine pop that CRYPTO_EX_DATA_FUNCS struct off the stack when it gets
> unloaded.
>
> Would hwcrhk_finish() be a good spot to do this? What call would one make
> to get this particular stack cleaned up? The struct was pushed onto the
> stack by calling RSA_get_ex_new_index() in hwcrhk_init() on e_chil.c:603,
> but I don't see an equivalent function to remove that particular ex_data and
> clear its helper functions.
>
> What would be best?
>
Unfortunately there is no way to do this with the existing ex_data API and
we'd rather avoid extending APIs in the stable branches if possible.
My suggestion would be to follow the same route I did with the compression
ex_data: avoid the use of the ex_data free handler entirely and free up the
ex_data pointer elsewhere.
Since this is an RSA structure you can add a "finish" handler to contain the
necessary functionality.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
