php5-svn seg fault when repos_url is https

[Anders Sandblad]

Tested on Ubuntu 14.04 with php5-svn (1.0.2-2).
When doing a query to a remote repos with svn_ls or svn_cat (those are the only functions I've tested) over https the script seg faults at the end of executing the script, not during.

Test script:

<?php
  svn_auth_set_parameter(SVN_AUTH_PARAM_DEFAULT_USERNAME, "user");
  svn_auth_set_parameter(SVN_AUTH_PARAM_DEFAULT_PASSWORD, "pass");

//print_r(svn_ls("https://svn.host.se/svn/repos/trunk/"));
//print_r(svn_ls("https://svn.host.se/svn/repos/"));
$contents = svn_cat("https://svn.host.se/svn/repos/trunk/sw/2061.MSW/applications/il.c");
?>

All of those make the script output
Segmentation fault (core dumped)
at the end of executing the script.
Running with http instead of https works fine.

[Anders Sandblad (arune)]

Oh! This only happens when php5-curl is installed!!

[Anders Sandblad (arune)]

Tried reproduce this in a container:

lxc launch ubuntu:14.04 testphp
lxc exec testphp -- bash

apt install php5-cli php5-svn

create test.php according above script

php test.php gives no output

then install php5-curl:

apt install php5-curl

and then run the script again and see it fail with segmentation fault.

[Anders Sandblad (arune)]

root@testphp:~# valgrind php test.php
==3716== Memcheck, a memory error detector
==3716== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==3716== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==3716== Command: php test.php
==3716==

==3716== Warning: invalid file descriptor -1 in syscall close()
==3716== Jump to the invalid address stated on the next line
==3716== at 0xEE7CDB0: ???
==3716== by 0x53437AE: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3716== by 0x5341B75: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3716== by 0x535125F: sk_pop_free (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3716== by 0x5341EFB: ENGINE_cleanup (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3716== by 0x7BB64CD: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==3716== by 0x7BB6E68: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==3716== by 0x7B926B4: curl_global_cleanup (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==3716== by 0x7959C97: zm_shutdown_curl (in /usr/lib/php5/20121212/curl.so)
==3716== by 0x6F4692: module_destructor (in /usr/bin/php5)
==3716== by 0x6F9904: ??? (in /usr/bin/php5)
==3716== by 0x6FB107: zend_hash_graceful_reverse_destroy (in /usr/bin/php5)
==3716== Address 0xee7cdb0 is not stack'd, malloc'd or (recently) free'd
==3716==
==3716==
==3716== Process terminating with default action of signal 11 (SIGSEGV)
==3716== Access not within mapped region at address 0xEE7CDB0
==3716== at 0xEE7CDB0: ???
==3716== by 0x53437AE: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3716== by 0x5341B75: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3716== by 0x535125F: sk_pop_free (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3716== by 0x5341EFB: ENGINE_cleanup (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3716== by 0x7BB64CD: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==3716== by 0x7BB6E68: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==3716== by 0x7B926B4: curl_global_cleanup (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==3716== by 0x7959C97: zm_shutdown_curl (in /usr/lib/php5/20121212/curl.so)
==3716== by 0x6F4692: module_destructor (in /usr/bin/php5)
==3716== by 0x6F9904: ??? (in /usr/bin/php5)
==3716== by 0x6FB107: zend_hash_graceful_reverse_destroy (in /usr/bin/php5)
==3716== If you believe this happened as a result of a stack
==3716== overflow in your program's main thread (unlikely but
==3716== possible), you can try to increase the size of the
==3716== main thread stack using the --main-stacksize= flag.
==3716== The main thread stack size used in this run was 8388608.
==3716==
==3716== HEAP SUMMARY:
==3716== in use at exit: 3,561,791 bytes in 18,770 blocks
==3716== total heap usage: 26,502 allocs, 7,732 frees, 5,611,800 bytes allocated
==3716==
==3716== LEAK SUMMARY:
==3716== definitely lost: 0 bytes in 0 blocks
==3716== indirectly lost: 0 bytes in 0 blocks
==3716== possibly lost: 0 bytes in 0 blocks
==3716== still reachable: 3,561,791 bytes in 18,770 blocks
==3716== suppressed: 0 bytes in 0 blocks
==3716== Rerun with --leak-check=full to see det...

[Anders Sandblad (arune)]

Backtrace from gdb:

#0 0x00007fffedf9bdb0 in ?? ()
#1 0x00007ffff76a27af in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#2 0x00007ffff76a0b76 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#3 0x00007ffff76b0260 in sk_pop_free () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#4 0x00007ffff76a0efc in ENGINE_cleanup () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#5 0x00007ffff52904ce in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#6 0x00007ffff5290e69 in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#7 0x00007ffff526c6b5 in curl_global_cleanup () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#8 0x00007ffff54b0c98 in zm_shutdown_curl () from /usr/lib/php5/20121212/curl.so
#9 0x00000000006f4693 in module_destructor ()
#10 0x00000000006f9905 in ?? ()
#11 0x00000000006fb108 in zend_hash_graceful_reverse_destroy ()
#12 0x00000000006ed17e in zend_shutdown ()
#13 0x000000000068f4bb in php_module_shutdown ()
#14 0x0000000000461c36 in main ()

[Anders Sandblad (arune)]

Fun, if one disable curl extension in php (by running php5dismod curl) and instead loading curl as argument to php like this:

php -dextension=/usr/lib/php5/20121212/curl.so test.php

Does not make it segfault but still works as expected.

[Steven MAYORGAS (msteven)]

Hi,

Same problem for me !
uname -a :
Linux ### 4.2.0-22-generic #27-Ubuntu SMP Thu Dec 17 22:57:08 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Do you have any news about it ?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Anders Sandblad (arune)]

No news, but there's no php-svn in php7 so I've rewritten most of my systems to not use php-svn.