https://bugs.kde.org/show_bug.cgi?id=524522
--- Comment #8 from Cesar Garcia <[email protected]> --- I did some debugging and found that the OpenSSL default provider was not available when the failure occurred. EVP_DecryptInit_ex() returned 0 with an empty OpenSSL error queue. I then tried initializing the same cipher using a fresh EVP_CIPHER_CTX, but that failed as well. An explicit: EVP_CIPHER_fetch(nullptr, "AES-128-CBC", nullptr) also returned nullptr, again without adding anything to the error queue. This indicates that the crash in EVP_CIPHER_CTX_set_key_length() was secondary: QCA continued using the context after the preceding initialization had failed. The documentation for the default provider [1] says: “If an attempt to load a provider has already been made (whether successful or not) then the default provider won't be loaded automatically. Therefore if the default provider is to be used in conjunction with other providers then it must be loaded explicitly.” QCA explicitly loads the legacy provider, but it does not explicitly load the default provider. Although QCA passes retain_fallbacks=1 to OSSL_PROVIDER_try_load(), and this should normally preserve fallback-provider activation, the default provider was unavailable in the affected PAM-started ksecretd process. I modified QCA to explicitly load the default provider before loading the legacy provider: OSSL_PROVIDER_try_load(nullptr, "default", 1); With this change, I can no longer reproduce the crash. I tested it across multiple complete reboots, and ksecretd remained stable. This suggests that the problem is related to QCA relying on implicit activation of the default provider. The attached patch makes that dependency explicit. [1] https://docs.openssl.org/3.6/man7/OSSL_PROVIDER-default/ -- You are receiving this mail because: You are watching all bug changes.
