From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 196762ED154; Tue, 25 Aug 2026 13:38:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787665132; cv=none; b=E2ZDfvC5fm4iUwJsRyAjaVZvsMLnM/7vKkDFeIt+iBqbiQ/zYvdyI48tsm5q/pLOsA+MMy4wXjugYVKsjfntK9SnSAx0XCVadK+ZRnEfecmaNIN9UQfjbzmeifQZdPR9ZZf9rZalg2ad3/5m3S4MMTIjNTzoJXDhOC2sUpDDfdY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787665132; c=relaxed/simple; bh=UnoOAxh7EHqH5BSMyvK2m+y8s17Tl+SPIZdxE3GboNA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HddWZirWsaF7TaER2vmaYf1vmjzo3L4reqVFt0aVrafVR0uPQMruun6KcR8l3wVXz4VIOIVXAsJyZQL/xfKOG4U6l9+BU/cNHb3kNbLwEQ1/FG8ztsOXSbM9Lc52WcevpGShVf2hwQ/VWFUHTgI0nzfK43usYn+gX2/rvfRceq8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=YybYfQ0r; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="YybYfQ0r" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 312CB1F00A3A; Tue, 25 Aug 2026 13:38:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1787665130; bh=oZRmpMtZSuQCwpvd7zkXc1UKbNaTtzHlIUD4IdUARh8=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=YybYfQ0rZ4TqkRpx4cgIyKBhhsFgqyJ//aAfh9zAcwxR2tAmYdL7pk//jso6YQWEt XuKbUGNquCXkswd7nLq0sGj8czruDpPzacqPlJANxaaEiOGITrfu7+CRat9YWl+Dnf jN0ONCWCkPThvFlL4EHTXwQfaoBMVSlmb/NElS5g= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Woraphat Khiaodaeng , Jens Axboe Subject: [PATCH 6.18 18/94] io_uring/cmd: fix iovec leak when the async cmd is not recycled Date: Tue, 25 Aug 2026 15:25:14 +0200 Message-ID: <20260825132542.607934429@linuxfoundation.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260825132541.887883084@linuxfoundation.org> References: <20260825132541.887883084@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Woraphat Khiaodaeng commit bb34ae5da3365699d53a756f4c96b6ea9f8ba0c1 upstream. An io_async_cmd carries an iovec array in ->vec.iovec, allocated when the vec has to grow and kept across recycling through ctx->cmd_cache. On two paths nothing frees it and io_clean_op()'s kfree(req->async_data) drops the io_async_cmd without it. io_req_uring_cleanup() clears the async data flags only when io_alloc_cache_put() succeeds, and the cache holds IO_ALLOC_CACHE_MAX == 128 entries, so once it is full the put fails and the vec is left behind. An NVMe passthrough workload gets there without doing anything unusual: nvme_uring_cmd_io() returns -EIOCBQUEUED, so the io_async_cmd stays attached for the lifetime of the command and the live object count tracks the queue depth. Above 128 the puts start failing. ->cleanup is the last chance to free an inherited vec, since io_req_uring_cleanup() returns early for an io-wq issued command and is not called at all for one completed without ever being issued. But io_clean_op() calls ->cleanup only if REQ_F_NEED_CLEANUP is set, and for uring_cmd that happens only where the vec has to grow, so a command reusing a large enough cached vec never sets it. io_rw_alloc_async() and io_msg_alloc_async() flag an inherited vec for exactly this reason; io_uring_cmd_prep() does not. Flag an inherited vec in io_uring_cmd_prep(), and free the vec when the cache put fails, as io_req_rw_cleanup() does. The leak is invisible under KASAN, where io_alloc_cache_vec_kasan() frees the vec unconditionally. Fixes: 3a4689ac109f ("io_uring/cmd: add iovec cache for commands") Cc: stable@vger.kernel.org Signed-off-by: Woraphat Khiaodaeng Link: https://patch.msgid.link/20260802073518.419-1-worapat.kd2@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman --- io_uring/uring_cmd.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/io_uring/uring_cmd.c +++ b/io_uring/uring_cmd.c @@ -38,6 +38,8 @@ static void io_req_uring_cleanup(struct if (io_alloc_cache_put(&req->ctx->cmd_cache, ac)) { ioucmd->sqe = NULL; io_req_async_data_clear(req, REQ_F_NEED_CLEANUP); + } else { + io_vec_free(&ac->vec); } } @@ -212,6 +214,8 @@ int io_uring_cmd_prep(struct io_kiocb *r ac = io_uring_alloc_async_data(&req->ctx->cmd_cache, req); if (!ac) return -ENOMEM; + if (ac->vec.iovec) + req->flags |= REQ_F_NEED_CLEANUP; ioucmd->sqe = sqe; return 0; }