"commit ssl cert" builds the new instances in several calls of its I/O handler: it yields every 10 instances, and whenever the output buffer is full. If the applet is released in between, for example because the CLI client closed the connection, cli_release_commit_cert() frees the new ckch_store of the transaction, but ckchs_transaction.new_ckchs, ckchs_transaction.old_ckchs and ckchs_transaction.path still reference it. The next "set ssl cert", "commit ssl cert", "abort ssl cert" or "show ssl cert" on this certificate then uses the freed store, which may crash the process or corrupt memory.
Only an admin of the CLI can trigger it, but it doesn't take much: a certificate used by more than 10 instances (e.g. in a crt-list loaded by several bind lines) and a client which doesn't wait for the end of the commit are enough. The release function is only called with a new store still attached when the transaction is being abandoned, the success path having consumed it in CERT_ST_INSERT, so the transaction is reset there. On the error path, CERT_ST_FIN already reset it and doing it again is harmless. "commit ssl ca-file" and "commit ssl crl-file" seem to follow the same pattern in cli_release_commit_cafile() and cli_release_commit_crlfile(), this will be addressed separately. This should be backported to all stable branches. Before 3.4, the release function is the same but frees ctx->new_ckchs itself instead of calling ckch_store_update_cleanup().
0001-BUG-MEDIUM-ssl-cli-reset-the-ongoing-transaction-whe.patch
Description: Binary data
