Re: [PATCH] nvme-fc: fix double free of fabrics options when nvme_add_ctrl() fails
Keith Busch <[email protected]>
| Newsgroups | org.infradead.lists.linux-nvme,org.kernel.vger.stable |
|---|---|
| Message-ID | <aocb3ogg34WWtRSB@kbusch-mbp> |
On Wed, Aug 19, 2026 at 08:32:33PM +0200, Niklas Cassel wrote: > Hello Keith, > > On Wed, Aug 19, 2026 at 09:28:08AM -0600, Keith Busch wrote: > > On Mon, Aug 17, 2026 at 05:10:23PM +0200, Niklas Cassel wrote: > > > It seems like Keith did prefer your patch, but as you said, your patch does > > > not avoid a NULL pointer dereference in nvme_auth_free(). > > > > But you're replacing a NULL pointer dereference to a derefence to freed > > memory. That should be fixed too, and I'm just saying checking a pointer > > for NULL before dereferencing it is more clear than checking if a list > > is empty. > > I am not following. > > The options is freed in two different places, depending on if the > ops->create_ctrl(dev, opts) call in fabrics.c:nvmf_create_ctrl() was > successful or not. Oh, not that path. You mentioned previously that ctrl->ops is dereferenced in other places. I thought this means we can successfully add the controller, which means the attributes are visible, but then fail something else later that causes the opts to free. Since the attribute was visible, something can open it before the device exporting is torn down, and access it after the opts were freed.