el_teardown_keyslot() decided whether to free a keyslot by calling ossl_qrl_enc_level_set_has_keyslot() against the EL's current state. On error paths the state does not yet match the slots that were provisioned, so the check returned 0 and the cctx and iv were leaked.

The fix drops the state check and rely on the existing cctx != NULL check which is sufficient for all callers of el_teardown_keyslot().

I have done some analysis of all callers to be really sure that it does rely on that check in any way. Specifically the current caller are:

• provide_secret() error path (both keyslots) - state is UNPROV, has_keyslot() returns 0 which is the leak that is being fixed
• key_cooldown_done() error path - slot is set up under PROV_NORMAL then torn down while state is still PROV_COOLDOWN which resulted in that check being false and another path that leaks.
• key_update() (TX) - state PROV_NORMAL, check already true so it still frees fine.
• key_update_done() - state PROV_UPDATING, check already true so it still frees the old slot.
• discard() (reachable from RX, TX, and INITIAL reprovision) - tears down both slots by index. In every state the slots holding a context already pass the check, or the misaligned slot is NULL and the inner guard no-ops it. No leak today, no behavioral change except a harmless cleanse of an unused IV.

So it should be hopefully safe to remove. :)