Bug #1678: uninitialized value in ossl_x509store_initialize causes occasional segfault

• Status: Closed
• Assignee: gotoyuzo (GOTOU Yuuzou)
• Target version: 1.9.2
• ruby -v: ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]

[peterp (Peter Pawlowski)]

=begin
I am seeing segfaults when attempting to run gem to install something on my build of Ruby 1.8.7 on a 64-bit linux machine.

When I use valgrind to try to figure out where it's failing, I see this suspicious output:

==19613== Conditional jump or move depends on uninitialised value(s)
==19613== at 0x60E5059: CRYPTO_set_ex_data (ex_data.c:597)
==19613== by 0x5E16F25: X509_STORE_set_ex_data (openssl_missing.c:42)
==19613== by 0x5E1C256: ossl_x509store_set_vfy_cb (ossl_x509store.c:115)
==19613== by 0x5E1C2DC: ossl_x509store_initialize (ossl_x509store.c:135)
==19613== by 0x4A48C79: call_cfunc (eval.c:5749)
==19613== by 0x4A47F7B: rb_call0 (eval.c:5904)
==19613== by 0x4A49714: rb_call (eval.c:6151)
==19613== by 0x4A49CEE: rb_funcall2 (eval.c:6287)
==19613== by 0x4A4CFA3: rb_obj_call_init (eval.c:7770)
==19613== by 0x4A7C991: rb_class_new_instance (object.c:1644)
==19613== by 0x4A48C79: call_cfunc (eval.c:5749)
==19613== by 0x4A47F7B: rb_call0 (eval.c:5904)

This should be easy to reproduce by just running gem install --local , which is how I am seeing the problem.

The problem appears to be that the GetX509Store macro is not initializing store->ex_data.sk for some reason.

I'm able to eliminate the problem by adding this line of code to the ossl_x509store_initialize function in ext/openssl/ossl_x509store.c, after the call to GetX509Store:

 store->ex_data.sk = NULL;

but I'm sure that this isn't the proper way to solve the problem. I tried to figure out why this is happening, but I don't understand the code well enough to make a suggestion, or a real patch.

I hope this is all the information you need, please let me know if there's anything else I can supply to help figure this out.
=end

[peterp (Peter Pawlowski)]

=begin
Ah, searching through the other issues, it looks like this is a duplicate of bug #405. Hopefully my additional information here is useful. This seems like a pretty serious problem.
=end

[yugui (Yuki Sonoda)]

• Category set to ext
• Status changed from Open to Assigned
• Assignee set to gotoyuzo (GOTOU Yuuzou)
• Priority changed from Normal to 6
• Target version set to 1.9.2

=begin

=end

[mame (Yusuke Endoh)]

• Status changed from Assigned to Closed
• % Done changed from 0 to 100

=begin
This issue was solved with changeset r27064.
Peter, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.

=end