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 1EDED3F8257 for ; Fri, 14 Aug 2026 14:44:02 +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=1786718644; cv=none; b=aTdIGTGGTfvbMNaWjTMvZDWNjQXmCFOE2H8B+BCU3tFbHSieZq4zoQcBDLxLOA5hGj/aiXo8d4OumCi+iocqXX9YdBIq+CZ6z/8tQ1ZEu42y9hoCdSywhJ0SD1I9ZT8TWOj9iVTE7GRPorG8CzLYKsOCRG1TarwR12tTQZnikqc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786718644; c=relaxed/simple; bh=Zt4H9ocC6u/a+H1WvZYHPKCEZ0jVnmzfB+ESIOUFC0g=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ltL816qBOK1LaLv7J7xGQQA0OOIFRD6mXFi3X/uEKYyVS+FLC2rOE72e6/zGiLXBi8u4aFQnXliXCmKA4xXZop78NbPWFfoQ5fkEoLTmViGdQ09kjD8yUuu8/XwdEGRRhnqiKWRzo/dNIt/FMQGBTw7Y8k2Nx8ud8uPc5fEaDWU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VSlu0czG; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="VSlu0czG" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4AA0C1F000E9; Fri, 14 Aug 2026 14:44:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786718642; bh=jbkaGCoYqQTj2DrafItBG9EZ2R7G8Oyso9YhZ31wUgE=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=VSlu0czGSHzzCkvn8DWPYHZDn6EUkQWu769ROrtRMpeIdbf1BpZOjiKfR5r3/HwR8 VjryX/tI7UIl97E433e4kHivigsHdrWPFfftqrU1Zaq2OhD8VpkpyQh6XlxVDcfDHy JJ3/oEEbANfyu1Ni/5LTQwaxIlwPaQHarFpZ9KHkMa9SGnzE3qSW/ehhmAatP1lrrN 336tTVuuurfzW43JQnnQ8fIkdZTD3xGp4oztMHkEswPDPl6ku2pXmB/ae2P188YmCt +GwiYEmWLq43wWLdRinTl5nKyIkcqz/hcPX84FXlfbZk+CoB0CSgsifathPzIB36QA hJuzNDG5Btqzg== Date: Fri, 14 Aug 2026 16:43:57 +0200 From: Niklas Cassel To: Rihyeon Kim Cc: kbusch@kernel.org, hch@lst.de, sagi@grimberg.me, axboe@kernel.dk, justin.tee@broadcom.com, nareshgottumukkala83@gmail.com, paul.ely@broadcom.com, kch@nvidia.com, linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, syzbot+f58e57380a6083c4041d@syzkaller.appspotmail.com Subject: Re: [PATCH v2] nvme-fc: fix double free of fabrics options when nvme_add_ctrl() fails Message-ID: References: <20260812122503.196828-1-rihyeon8648@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260812122503.196828-1-rihyeon8648@gmail.com> Hello Rihyeon, On Wed, Aug 12, 2026 at 09:25:03PM +0900, Rihyeon Kim wrote: > nvmf_create_ctrl() frees opts when ->create_ctrl() returns an error, so > a transport must not free it on its own error paths. nvme_fc_ctrl_free() > therefore only calls nvmf_free_options() while ctrl->ctrl.opts is still > set, and nvme_fc_init_ctrl() clears that pointer before its last put. > > It only does so on the fail_ctrl: path. When nvme_add_ctrl() fails, > nvme_fc_init_ctrl() jumps to out_put_ctrl: instead, so > nvme_fc_ctrl_free() still sees ctrl->ctrl.opts set and frees opts, and > nvmf_create_ctrl() frees it again. > > Reproduced with nvme-fcloop and failslab by failing the kvasprintf() in > dev_set_name(), called from nvme_add_ctrl(): > > BUG: KASAN: slab-use-after-free in nvmf_free_options+0x30/0x190 > nvmf_free_options+0x30/0x190 drivers/nvme/host/fabrics.c:1284 > nvmf_create_ctrl drivers/nvme/host/fabrics.c:1374 [inline] > Freed by task 5534: > nvme_fc_ctrl_free drivers/nvme/host/fc.c:2374 [inline] > nvme_fc_init_ctrl+0xe17/0x1450 drivers/nvme/host/fc.c:3605 > > Without KASAN, opts is freed twice. > > nvme-tcp and nvme-rdma reach the same error path, but their free_ctrl > only frees opts once the controller is on the global list, so they are > not affected. > > Move the clear down to out_put_ctrl:, which both error paths pass > through. The same injection then returns -EIO without a report. > > Fixes: 1a9e218195a5 ("nvme: split device add from initialization") > Cc: stable@vger.kernel.org > Reported-by: syzbot+f58e57380a6083c4041d@syzkaller.appspotmail.com > Closes: https://syzkaller.appspot.com/bug?extid=f58e57380a6083c4041d > Suggested-by: Keith Busch > Assisted-by: Claude:claude-opus-5 > Signed-off-by: Rihyeon Kim > --- I created an alternative fix that makes fc behave the same way as tcp/rdma/loop, i.e. derive ownership from seeing if the ctrl is on the list or not: https://lore.kernel.org/linux-nvme/20260814143833.1953415-2-cassel@kernel.org/T/#u This has the advantage of avoiding the NULL pointer dereferences in nvme_auth_free() and when accessing the sysfs attributes during teardown, as reported by Sashiko, as ctrl->ctrl.opts now stays valid for the whole teardown. Please review. Kind regards, Niklas