Skip to content
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

steam statically links against openssl build without engine support #4619

Closed
msmeissn opened this issue Sep 6, 2016 · 5 comments
Closed
Labels

Comments

@msmeissn
Copy link

msmeissn commented Sep 6, 2016

Your system information

  • Steam client version: 20160812
  • Distribution (e.g. Ubuntu): openSUSE Tumbleweed
  • Opted into Steam client beta?: [Yes/No] No
  • Have you checked for system updates?: [Yes/No] Yes

Please describe your issue in as much detail as possible:

Describe what you expected should happen and what did happen. Please link any large code pastes as a Github Gist

While debugging crashes on openSUSE Tumbleweed I see:

RSA_new is called in the "steam" binary, which likely links against a static build of openssl.
Later on from steamclient.so RSA_free() is called dynamically.

The RSA_new in "steam" itself is in an libcrypto without ENGINE support, the dynamic distribution libraries are however build with ENGINE support.

This RSA_new leads to the RSA struct having an uninitialized "engine" member, which is however accessed by the dynamic library and lead to crashes.

Steps for reproducing this issue:

@msmeissn
Copy link
Author

msmeissn commented Sep 6, 2016

i sent openssl this kind of pull request openssl/openssl#1539
which could be locally applied by the steam devs too.

@GreatBigWhiteWorld
Copy link

So will this be fixed by some one?

@boombatower
Copy link

Thanks @msmeissn!

This fix released in openSUSE Tumbleweed 20160924 and confirmed to work. Would be nice to see Valve take advantage of the work done here to fix and thus solve for all distros.

@kisak-valve
Copy link
Member

Hello @msmeissn, are you still experiencing this issue on an up to date system?

Mesa 17.0 imported an SHA-1 implementation for shader caching, which should have removed the main factor that caused users to encounter the crashes related to this issue.

@msmeissn
Copy link
Author

I am not using it, i was just reporting a problem by one of our users at that time.

For me it can be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants