From 406fd0ceb17c7ac9241989d865ab42330ed0cf23 Mon Sep 17 00:00:00 2001 From: William Lallemand Date: Sat, 27 Sep 2025 18:38:17 +0200 Subject: [PATCH] BUG/MINOR: acme: don't unlink from acme_ctx_destroy() Unlinking the acme_ctx element from acme_ctx_destroy() requires to have the element unlocked, because MT_LIST_DELETE() locks the element. acme_ctx_destroy() frees the data from acme_ctx with the ctx still linked and unlocked, then lock to unlink. So there's a small risk of accessing acme_ctx from somewhere else. The only way to do that would be to use the `acme challenge_ready` CLI command at the same time. Fix the issue by doing a mt_list_unlock_link() and a mt_list_unlock_self() to unlink the element under the lock, then destroy the element. This must be backported in 3.2. --- src/acme.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/acme.c b/src/acme.c index 4249638ca..ba4bf5905 100644 --- a/src/acme.c +++ b/src/acme.c @@ -845,7 +845,6 @@ static void acme_ctx_destroy(struct acme_ctx *ctx) X509_REQ_free(ctx->req); - MT_LIST_DELETE(&ctx->el); free(ctx); } @@ -2362,8 +2361,10 @@ abort: ha_free(&errmsg); end: - MT_LIST_UNLOCK_FULL(&ctx->el, tmp); acme_del_acme_ctx_map(ctx); + /* unlink ctx from the mtlist then destroy */ + mt_list_unlock_link(tmp); + mt_list_unlock_self(&ctx->el); acme_ctx_destroy(ctx); task_destroy(task); task = NULL; -- 2.47.3