Debian Patches
Status for softhsm2/2.6.1-3.1
| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| 0001-Issue-548-Don-t-clean-up-engines-after-OpenSSL-has-a.patch | Issue #548: Don't clean up engines after OpenSSL has already shut down As of 1.1.0, OpenSSL registers its own atexit() handler to call OPENSSL_cleanup(). If our own code subsequently tries to, for example, unreference an ENGINE, then it'll crash or deadlock with a use after free. Fix it by registering a callback with OPENSSL_atexit() to be called when OPENSSL_cleanup() is called. It sets a flag which prevents any further touching of OpenSSL objects — which would otherwise happen fairly much immediately thereafter when our own OSSLCryptoFactory destructor gets called by the C++ runtime's own atexit() handler. |
David Woodhouse <dwmw2@infradead.org> | no | 2020-05-04 | ||
| 0002-Fix-OPENSSL_cleanup-detection-without-using-our-own-.patch | Fix OPENSSL_cleanup() detection without using our own atexit() handler We can't register our own atexit() or OPENSSL_atexit() handler because there's no way to unregister it when the SoftHSM DSO is unloaded. This causes the crash reported at https://bugzilla.redhat.com/1831086#c8 Instead of using that method to set a flag showing that OPENSSL_cleanup() has occurred, instead test directly by calling OPENSSL_init_crypto() for something that *would* do nothing, but will fail if OPENSSL_cleanup() has indeed been run already. has already shut down" |
David Woodhouse <dwmw2@infradead.org> | no | 2020-05-13 | ||
| 0003-fix-ftbfs-with-opensslv3.patch | [PATCH 1/4] openssl 3.0: Run DES tests only if OpenSSL allows it OpenSSL 3.0 moves DES into a legacy provider which has to be loaded explicitly. By default, it will not be loaded and DES methods in tests will fail. Nest test blocks under successful initialization. |
Alexander Bokovoy <abokovoy@redhat.com> | no | 2021-05-26 | ||
| 0004-Fix-ForkTest-by-exiting-from-child.patch | Fix ForkTest by exiting from child The ForkTest was causing a race conditions with other tests as the forked child continued to run. This is fixed by exiting from the child. |
Jakub Zelenka <bukka@php.net> | no | 2025-06-20 | ||
| 0005-Never-destroy-singletons-teardown.patch | Never destroy module-wide singletons via static teardown (#897) SoftHSM::instance, MutexFactory::instance, SecureMemoryRegistry::instance, and OSSLCryptoFactory::instance/BotanCryptoFactory::instance were each a class-level static std::unique_ptr<T> (or std::auto_ptr<T> pre-C++11). Their destructors ran as part of the C++ runtime's ordinary static-object teardown at process exit - an indeterminate time relative to unrelated code's own cleanup. open sessions at process exit calls C_CloseSession() on each before calling C_Finalize(), per the PKCS#11 spec. But SoftHSM::instance's own destructor could fire first, via ordinary static teardown, independently of and unordered with respect to that caller's explicit cleanup sequence. Whichever teardown path lost the race operated on an already-destroyed (or transparently reconstructed-blank, since SoftHSM::i() rebuilds a fresh instance on next access) singleton, and its stale session-close calls then dereferenced a NULL member on it - a real, reproducible SIGSEGV when a pkcs11-provider-based caller runs openssl req against a PKCS#11 key and exits normally. This is the same category of bug already fixed once for OSSLCryptoFactory's own OpenSSL ENGINE cleanup (issue #548, commit c2cc065), just never applied to these singletons' own top-level lifecycle - and the gap resurfaces one level down too: OSSLCryptoFactory can be lazily constructed for the first time from deep inside SoftHSM::C_Finalize()'s own teardown chain, touching ENGINE_by_id() after OpenSSL's own OPENSSL_cleanup() has already run. Each singleton's std::unique_ptr<T>/std::auto_ptr<T> is now heap-allocated once and deliberately never freed, so nothing destroys the T it owns except that class's own explicit reset()/C_Finalize() path - never ordinary static teardown. The smart pointer itself is retained as the owning type (matching the "Static and Global Variables" guidance in the Google C++ Style Guide, and the same "leaky singleton" idiom used by e.g. Drake's never_destroyed<T>), so reset()'s exception-safety and ownership semantics for the owned object are unchanged. |
Rikard Söderström <Rikard.Soderstrom@permobil.com> | no | upstream, 9ad87341c94ffdf1364ecf27b715475e0d80b0dd | 2026-10-03 |