<div dir="ltr"><div>I've got a SUSE 15.1 install (on ppc64le) that kernel panics on a very simple<br>test program, built in a slightly unusual way.<br><br>I'm compiling on SUSE 12, using gcc 4.8.3. I'm linking to a static<br>copy of libcrypto.a (from openssl-1.1.1g), built without threads.<br>I have a 10 line C test program that compiles and runs fine on the<br>SUSE 12 system. If I compile the same program on SUSE 15.1 (with</div><div>gcc 7.4.1), it runs fine on SUSE 15.1.<br><br>But, if I run the version that I compiled on SUSE 12, on the SUSE 15.1<br>system, the call to RAND_status() gets to a malloc() and then panics.<br>(And, of course, if I just compile a call to malloc(), that runs fine<br>on both systems.) Here's the test program, it's really just a call to<br>RAND_status():<br><br>    #include <stdio.h><br>    #include <openssl/rand.h><br><br>    int main(int argc, char **argv)<br>    {<br>        int has_enough_data = RAND_status();<br>        printf("The PRNG %s been seeded with enough data\n",<br>               has_enough_data ? "HAS" : "has NOT");<br>        return 0;<br>    }<br><br>openssl is configured/built with:<br>    ./config no-shared no-dso no-threads -fPIC -ggdb3 -debug -static<br>    make<br><br>and the test program is compiled with:<br>    gcc -ggdb3 -o rand_test rand_test.c libcrypto.a<br><br>The kernel on SUSE 12 is: 3.12.28-4-default<br>And glibc is: 2.19<br><br>The kernel on SUSE 15.1 is: 4.12.14-197.18-default<br>And glibc is: 2.26<br><br>In a previous iteration it was panicking in pthread_once(), so<br>I compiled openssl without pthreads support, and now it panics<br>calling malloc().<br><br>If I link to the system-supplied libcrypto.so, it works fine, and<br>running the same tests on x86_64 works fine, it's only ppc64le<br>that panics, and only running code from the old system on the</div><div>new one.<br><br>I'm trying to dig further down into this to come up with a standalone<br>test case, but I'm wondering if anything here stands out as a known<br>problem, or if someone can point me in the right direction.<br><br>Thanks,<br>Carl Jacobsen</div></div>