Linux: mssql driver libraries force load libssl.so and libcrypto.so, leads to deadlock when openssl is already loaded

[henderkes]

PHP version

8.X

PHP SQLSRV or PDO_SQLSRV version

ExtensionVer => 5.12.0

Microsoft ODBC Driver version

libmsodbcsql-18.6.so.1.1

SQL Server version

2022

Client operating system

Debian/Almalinux

Problem description

We have a php binary that statically links in openssl and openssl extension, to make it portable across all linux distros. This php binary can connect just fine with ssl to pgsql, mariadb, mysql and sqlite. However, when loading trying to connect to a mssql server using the sqlsrv extension, the mssql driver loads libssl.so and libcrypto.so in the version that is installed on the operating system, instead of using the ssl symbols already present in the binary. This seems to create a conflict of some kind and the program deadlocks.

<?php
<?php
$serverName = "sqlserver,1433";
$connectionOptions = [
    "Database" => "master",
    "Uid" => "sa",
    "PWD" => "YourStrong!Pass123",
    "TrustServerCertificate" => true
];
$conn = sqlsrv_connect($serverName, $connectionOptions);
if ($conn === false) {
    echo "Connection failed for " . phpversion() . ":\n";
    die(print_r(sqlsrv_errors(), true));
}
echo "Connection Successful using PHP " . phpversion() . "!\n";
sqlsrv_close($conn);
?>

Expected behavior and actual behavior

Expected: Connection Successful using PHP 8.4.18!
Actual: deadlock

sendto(5, "\22\1\0X\0\0\1\0\0\0\37\0\6\1\0%\0\1\2\0&\0\1\3\0'\0\4\4\0+\0"..., 88, MSG_NOSIGNAL, NULL, 0) = 88
poll([{fd=5, events=POLLIN}], 1, 14993) = 1 ([{fd=5, revents=POLLIN}])
recvfrom(5, "\4\1\0000\0\0\1\0\0\0\37\0\6\1\0%\0\1\2\0&\0\1\3\0'\0\0\4\0'\0"..., 4096, 0, NULL, NULL) = 48
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 6
newfstatat(6, "", {st_mode=S_IFREG|0644, st_size=18447, ...}, AT_EMPTY_PATH) = 0
mmap(NULL, 18447, PROT_READ, MAP_PRIVATE, 6, 0) = 0x7ffb23734000
close(6)                                = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libssl.so.3", O_RDONLY|O_CLOEXEC) = 6
read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 832) = 832
newfstatat(6, "", {st_mode=S_IFREG|0644, st_size=688160, ...}, AT_EMPTY_PATH) = 0
mmap(NULL, 690288, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x7ffb2258d000
mmap(0x7ffb225ac000, 380928, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x1f000) = 0x7ffb225ac000
mmap(0x7ffb22609000, 126976, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x7c000) = 0x7ffb22609000
mmap(0x7ffb22628000, 57344, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x9a000) = 0x7ffb22628000
close(6)                                = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libcrypto.so.3", O_RDONLY|O_CLOEXEC) = 6
read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 832) = 832
newfstatat(6, "", {st_mode=S_IFREG|0644, st_size=4734232, ...}, AT_EMPTY_PATH) = 0
mmap(NULL, 4748720, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x7ffb22105000
mmap(0x7ffb221ca000, 2609152, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0xc5000) = 0x7ffb221ca000
mmap(0x7ffb22447000, 909312, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x342000) = 0x7ffb22447000
mmap(0x7ffb22525000, 413696, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x41f000) = 0x7ffb22525000
mmap(0x7ffb2258a000, 9648, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7ffb2258a000
close(6)                                = 0
mprotect(0x7ffb22525000, 401408, PROT_READ) = 0
mprotect(0x7ffb22628000, 40960, PROT_READ) = 0
munmap(0x7ffb23734000, 18447)           = 0
futex(0x5650e7242560, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7ffb22635864, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7ffb22635858, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7ffb22635838, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7ffb225898e8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x5650e7241dc8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
brk(0x56512523e000)                     = 0x56512523e000
futex(0x5650e72426e0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7ffb22589824, FUTEX_WAKE_PRIVATE, 2147483647) = 0

• indefinite hang -

Repro code or steps to reproduce

• Install openssl-dev

• link php with openssl and sqlsrv extension against libssl.a and libcrypto.a

• run test connection script -> deadlock

• link php with openssl and sqlsrv extension against libssl.so and libcrypto.so

• run test connection script -> success

[jahnvi480]

Thanks @henderkes for reporting this issue, I'll try to reproduce and will check with ODBC team for the same.

[henderkes]

Sure, would you like a reproducer in the form of two Dockerfiles?

[jahnvi480]

Thank you for reporting this. We've looked into it and this is not an issue in the PHP drivers (sqlsrv / PDO_SQLSRV).

The Microsoft ODBC Driver for SQL Server dynamically loads the system's libssl.so and libcrypto.so at connection time via dlopen. When your PHP binary has OpenSSL statically linked, two separate copies of OpenSSL end up in the process with conflicting global state and locks, which causes the deadlock you're seeing.

The PHP extension itself does not interact with OpenSSL — it is the ODBC driver that loads it.

Workarounds:

1. Link PHP against shared OpenSSL (libssl.so / libcrypto.so) instead of static libraries — this is the recommended approach and what you've already confirmed works.
2. If shared linking is not an option and your environment allows it, you can set Encrypt=no in the connection string to prevent the ODBC driver from loading OpenSSL. This is only appropriate for trusted networks or development environments.

[henderkes]

Hi, thanks for getting back to me.

The PHP extension itself does not interact with OpenSSL — it is the ODBC driver that loads it.

Yes, it's the mssql odbc driver, to be exact. I have not looked into specifics, but the pgsql odbc driver and mysql odbc driver both manage to connect to databases with ssl, even when loaded by the same php binary with openssl in it.

(Of course it doesn't make sense to use the odbc drivers as the pgsql/mysql drivers can already be statically linked into the php binary, but that's besides the point.)

• Link PHP against shared OpenSSL (libssl.so / libcrypto.so) instead of static libraries — this is the recommended approach and what you've already confirmed works.

This kind of works, but will necessitate building and shipping openssl with the program, while the entire point is letting users ship their php software as a single executable file.

• If shared linking is not an option and your environment allows it, you can set Encrypt=no in the connection string to prevent the ODBC driver from loading OpenSSL. This is only appropriate for trusted networks or development environments.

This doesn't work, I don't know why, but the mssql driver hangs the php process regardless of whether a connection is attempted with or without encryption.

[David-Engel]

• If shared linking is not an option and your environment allows it, you can set Encrypt=no in the connection string to prevent the ODBC driver from loading OpenSSL. This is only appropriate for trusted networks or development environments.

This doesn't work, I don't know why, but the mssql driver hangs the php process regardless of whether a connection is attempted with or without encryption.

The ODBC still uses encryption to encrypt the login packet, whether encryption is used for the entire connection or not (Encrypt=no). Thus, ODBC will still load the OpenSSL libraries.

From the ODBC side, the choice was made to dynamically load the system-installed OpenSSL libraries at runtime to support multiple OpenSSL versions in a single binary. This was likely done when OpenSSL 3.x was new and not all supported distros had it, yet. It does come with the downside of being incompatible with applications that statically link OpenSSL.

This is technically external to the msphpsql library, but I'll file a feature request with the ODBC team (not publicly visible) to support using already-loaded versions of OpenSSL, if possible.

[henderkes]

Thank you, that's great to hear. Please keep me updated in this thread.