Re: [PATCH] dmaengine: idxd: fix double free in idxd_alloc() error path

[Vinicius Costa Gomes <vinicius.gomes@intel.com>]

Hi,

Guangshuo Li <lgs201920130244@gmail.com> writes:

> When dev_set_name() fails after device_initialize(), idxd_alloc()
> calls put_device(conf_dev).
>
> For these devices, conf_dev->type is set from idxd->data->dev_type,
> which resolves to dsa_device_type or iax_device_type, and both use
> idxd_conf_device_release() as their release callback.
>
> That release callback frees idxd, idxd->opcap_bmap, and releases
> idxd->id, but the current error path then frees those resources again
> directly, causing a double free.
>
> Keep the cleanup in idxd_conf_device_release() after put_device() and
> avoid freeing idxd-managed resources again in idxd_alloc().
>
> Fixes: 46a5cca76c76 ("dmaengine: idxd: fix memory leak in error handling path of idxd_alloc")
> Cc: stable@vger.kernel.org
> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>

My preference is for the maintainer making the pull request to decide if
something should be sent to stable or not.

I was trying some AI review bot, I hope you don't mind, and got these
comments, went through them and they seemed good (including that these
patches should be sent as a series, that there are some more work to do
while you are cleaning the error paths), including it verbatim here:

This patch removes bitmap_free(idxd->opcap_bmap) after put_device()
in idxd_alloc()'s err_name path and adds a return NULL to prevent
falling through to the err_opcap and err_ida labels, avoiding
double-frees of opcap_bmap, ida, and idxd itself.

> diff --git a/drivers/dma/idxd/init.c b/drivers/dma/idxd/init.c
> index 4eff74182225..94ce52565e7a 100644
> --- a/drivers/dma/idxd/init.c
> +++ b/drivers/dma/idxd/init.c
> @@ -635,7 +635,7 @@ static struct idxd_device *idxd_alloc(struct pci_dev *pdev, struct idxd_driver_d
>
>  err_name:
>  	put_device(conf_dev);
> -	bitmap_free(idxd->opcap_bmap);
> +	return NULL;
>  err_opcap:
>  	ida_free(&idxd_ida, idxd->id);
>  err_ida:

The double-free analysis is correct, but does the put_device() above
actually work here?

put_device(conf_dev) drops the refcount from 1 to 0 (no device_add()
was called, so nobody else holds a reference) and triggers the release
callback idxd_conf_device_release(), which does:

  idxd_conf_device_release() {
      destroy_workqueue(idxd->wq);
      ...
  }

At this point in idxd_alloc(), idxd->wq is still NULL -- the
workqueue is created much later in idxd_setup_internals():

  idxd_setup_internals() {
      ...
      idxd->wq = create_workqueue(dev_name(dev));
      ...
  }

destroy_workqueue() does not handle a NULL argument -- it immediately
dereferences the pointer:

  destroy_workqueue(wq) {
      workqueue_sysfs_unregister(wq);
      mutex_lock(&wq->mutex);          <-- NULL dereference
      ...
  }

So put_device() here will oops before the double-free is even
reached. This is a pre-existing issue (the old code has the same
put_device call), but relying on idxd_conf_device_release() as the
cleanup path for a partially-initialized idxd_device doesn't work.

Would it make sense to skip put_device() and instead free only
what was allocated, similar to the err_opcap and err_ida labels?

Two more things worth noting about this series:

Patch 3 (idxd_setup_engines) includes hunks that remove blank lines
from idxd_setup_groups() -- lines that only exist after Patch 2 is
applied. These four patches should probably be sent as a numbered
series with an explicit ordering rather than as independent patches.

The same put_device()-then-kfree() pattern also exists in
idxd_clean_wqs(), idxd_clean_engines(), idxd_clean_groups(), and
idxd_free(), which are not addressed by this series. It might be
worth fixing all of them together.


Cheers,
-- 
Vinicius