Loading the configuration only once will resolve this issue, and is the recommended code fix.
On top of this bug fix, and as mentioned above, we recommend that future versions will incorporate an API change that will shift the ownership on releasing the pointers to the engine that allocated them on the first place. We understand this is an API change and that it isn't relevant in the near future. Regarding workarounds that will apply till OpenSSL fix their double loading of the configuration, as I mentioned in #35, we are at a loss here because OpenSSL is actively freeing the memory that the engine allocated. The struct ENGINE is an OpenSSL implementation detail, and is allocated in an OpenSSL function ENGINE_new(). I fail to see how a given engine can add fields to it / save its own context on top of it. 1. The engine library could maintain some Data structure with all "known" engine instances of itself, but OpenSSL guaranteed developers a singleton invocation. This is a drastic implementation change on behalf of the engine developers, and I doubt developers will go to this effort when they know it is temporary until OpenSSL fixes their code and restore back the singleton guarantee. 2. It is a bit trickier, because OpenSSL expect the memory to be initialized using EVP_PKEY_meth_new() and then the pointer to be set using EVP_PKEY_meth_set_derive(). Hence, they've taken the liberty to invoke EVP_PKEY_meth_free() and directly free the instance that was given to them. If all engine instances use the same static field, it will get freed by OpenSSL. If there will be an instance per engine, it throws us back to point (1) of maintaining a data structure of the additional engine metadata per instance. 3. In our deployment environments any environment variable based hack is out of the question. As such, any temporary fix will be a hack, and will need to bypass the break of the singleton engine guarantee that was given to engine developers. Disabling the double parsing of the configuration, and double load of the engine is the code fix that should be done, and it should be done on OpenSSL's side. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1921518 Title: OpenSSL "double free" error Status in openssl package in Ubuntu: Incomplete Status in openssl source package in Focal: Incomplete Bug description: "double free" error is seen when using curl utility. Error is from libcrypto.so which is part of the OpenSSL package. This happens only when OpenSSL is configured to use a dynamic engine. OpenSSL version is 1.1.1f The issue is not encountered if http://www.openssl.org/source/openssl-1.1.1f.tar.gz is used instead. OpenSSL can be configured to use a dynamic engine by editing the default openssl config file which is located at '/etc/ssl/openssl.cnf' on Ubuntu systems. On Bluefield systems, config diff to enable PKA dynamic engine, is as below: +openssl_conf = conf_section + # Extra OBJECT IDENTIFIER info: #oid_file = $ENV::HOME/.oid oid_section = new_oids +[ conf_section ] +engines = engine_section + +[ engine_section ] +bf = bf_section + +[ bf_section ] +engine_id=pka +dynamic_path=/usr/lib/aarch64-linux-gnu/engines-1.1/pka.so +init=0 + engine_id above refers to dynamic engine name/identifier. dynamic_path points to the .so file for the dynamic engine. # curl -O https://tpo.pe/pathogen.vim double free or corruption (out) Aborted (core dumped) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1921518/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
