New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[debian9] libssl1.0.0 and libssl1.0.2 can end up loaded in same process causing crashes #23796
Comments
Ah: the callstack shows a callback traversing up from ssl 1.0.2, through libcoreclr, back down to ssl 1.0.0:
|
I think I'll need to add a way to enable overriding the libssl we load (via an env var). I cannot see a reasonable automatic way to resolve the problem. If I switched the search order (first 1.0.2, then 1.0.0), then it would create the same potential issue on other distros where curl is built against libssl 1.0.0, but someone installs the 1.0.2 side by side with it. |
Through some combination of Would that be an appropriate solution? |
@DHowett-MSFT the issue is that the libcurl doesn't have to be loaded yet at the point when we load libssl. The libcurl is loaded only if System.Net.Http.dll is used and libssl when System.Security.Cryptography.dll is used. |
Maybe we could try to change the System.Security.Cryptography.Native.OpenSSL.so to load libssl indirectly by loading libcurl, but that's kind of ugly since it pulls quite a lot of other libraries into the process and if someone is using just the crypto stuff and no https, then it would be waste of space. |
those pages would be easily releasable as OS knows it is backed by file. |
In this case, it looks like that’s what’s happening. A callback through 1.0.2 is ending up serviced by a 1.0.0 consumer with 1.0.0 X509 APIs. RTLD_LOCAL won’t really help with that. |
One important thing to note is that having these two libraries is a non-standard situation. There is no official 1.0.0 package for Debian 9, only 1.0.2. That's why I was suggesting treating it by adding a way to explicitly override the selection in the unlikely case someone has both versions due to some unknown reason. Please correct me if this assumption is wrong and it is a more wide-spread case. |
It looks like it came in when I transitioned from Debian 8. I have a few packages currently installed that depend on it, many of which seem important. Thanks for the tip on it being non-standard, however. I could have sworn it was standard-issue! Since that's the case, perhaps there's little value in fixing this issue. |
@DHowett-MSFT I had the same problem with the transition from Debian 8. The weirdest thing was that there was no error on the .NET side. My API terminated as if performing an expected shutdown (exit code 0). That is a pretty major bug in my books, but the underlying cause was my misconfigured system. Uninstalling libssl1.0.0 was the solution for me. |
Since we've already marked dotnet/corefx#24891 for inclusion in the 2.1 release, closing this copy of the issue. |
On Debian 9, curl depends on libssl1.0.2. When the libssl1.0.0 and libssl1.0.2 packages are both installed on a machine,
System.Security.Cryptography.Native.Openssl
will preferentially loadlibssl.so.1.0.0
.System.Net.Http.Native
, however, loadslibcurl.so
, which in turn loadslibssl.so.1.0.2
.Repro
Some combination (as yet undetermined; the repro is "open PowerShell 6.0.0-beta.8, wait a while") of interacting with the members of these assemblies, or of passing SSL contexts between System.Net.Http and System.Security.Cryptography.Openssl will trigger a segmentation violation and subsequent termination.
Dependency Graph
Resolution
Not sure.
libssl.so.1.0.2
?The text was updated successfully, but these errors were encountered: