From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 B54C12264AB; Tue, 30 Sep 2025 14:51:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759243863; cv=none; b=iXfjT4D2YrYJQNbH+uEGTijnxsbYglizQaOhh0uarPLeoqEEDb3R3nFdwYgGcQ84f3EEYWYEtJaKo+KFSM0spPNpDcy0QcMkSpvySF3qbX7Qq4qLT8m72Zbgb5YQM6ECPapJe8p18au0K4GdOslaw7GzvLqG1oi2M785gu0/Lyo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759243863; c=relaxed/simple; bh=R113HF2wk9SvYxlkFvgTCb/IIdwscJqwccJzOaQ8JBE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=A7ComUAvKpTrtoKRnYNZ47lEIPhzFlWt8SImbYQVPU35fFT2TJDRHUnJGJ1Ua7v6ZLcUDGz0RfIxUg00YVdHXrKqq7X6ddSuwpTgdVtjtdhkjQq4N64Zn69d5VDW1tf6V0iemVRgyZt5cikgp9waQN+mY64jRp5cPNL1CpvaSHs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=ptFY5VW2; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="ptFY5VW2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 236F3C4CEF0; Tue, 30 Sep 2025 14:51:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1759243863; bh=R113HF2wk9SvYxlkFvgTCb/IIdwscJqwccJzOaQ8JBE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ptFY5VW274k2PZp6bZRssvGQD43LalKgtZ6GQwoUstGq0IChRlLBMop1Dl55aYbXC I5JNlOasDpsavJKnOzxt0ASmQpqFEbVLYiUJV6gEWDFnWuYUdgnJul6k9TvAcQ/iRY vDxhtr/qKS0XPrdnrVbKCGVJtgxN37yd58TcheUA= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Duoming Zhou , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.4 40/81] cnic: Fix use-after-free bugs in cnic_delete_task Date: Tue, 30 Sep 2025 16:46:42 +0200 Message-ID: <20250930143821.351554120@linuxfoundation.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20250930143819.654157320@linuxfoundation.org> References: <20250930143819.654157320@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-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 5.4-stable review patch. If anyone has any objections, please let me know. ------------------ From: Duoming Zhou [ Upstream commit cfa7d9b1e3a8604afc84e9e51d789c29574fb216 ] The original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(), which does not guarantee that the delayed work item 'delete_task' has fully completed if it was already running. Additionally, the delayed work item is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only blocks and waits for work items that were already queued to the workqueue prior to its invocation. Any work items submitted after flush_workqueue() is called are not included in the set of tasks that the flush operation awaits. This means that after the cyclic work items have finished executing, a delayed work item may still exist in the workqueue. This leads to use-after-free scenarios where the cnic_dev is deallocated by cnic_free_dev(), while delete_task remains active and attempt to dereference cnic_dev in cnic_delete_task(). A typical race condition is illustrated below: CPU 0 (cleanup) | CPU 1 (delayed work callback) cnic_netdev_event() | cnic_stop_hw() | cnic_delete_task() cnic_cm_stop_bnx2x_hw() | ... cancel_delayed_work() | /* the queue_delayed_work() flush_workqueue() | executes after flush_workqueue()*/ | queue_delayed_work() cnic_free_dev(dev)//free | cnic_delete_task() //new instance | dev = cp->dev; //use Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the cyclic delayed work item is properly canceled and that any ongoing execution of the work item completes before the cnic_dev is deallocated. Furthermore, since cancel_delayed_work_sync() uses __flush_work(work, true) to synchronously wait for any currently executing instance of the work item to finish, the flush_workqueue() becomes redundant and should be removed. This bug was identified through static analysis. To reproduce the issue and validate the fix, I simulated the cnic PCI device in QEMU and introduced intentional delays — such as inserting calls to ssleep() within the cnic_delete_task() function — to increase the likelihood of triggering the bug. Fixes: fdf24086f475 ("cnic: Defer iscsi connection cleanup") Signed-off-by: Duoming Zhou Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin --- drivers/net/ethernet/broadcom/cnic.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/ethernet/broadcom/cnic.c b/drivers/net/ethernet/broadcom/cnic.c index 155599dcee76d..3283f66e02b6e 100644 --- a/drivers/net/ethernet/broadcom/cnic.c +++ b/drivers/net/ethernet/broadcom/cnic.c @@ -4224,8 +4224,7 @@ static void cnic_cm_stop_bnx2x_hw(struct cnic_dev *dev) cnic_bnx2x_delete_wait(dev, 0); - cancel_delayed_work(&cp->delete_task); - flush_workqueue(cnic_wq); + cancel_delayed_work_sync(&cp->delete_task); if (atomic_read(&cp->iscsi_conn) != 0) netdev_warn(dev->netdev, "%d iSCSI connections not destroyed\n", -- 2.51.0