Re: [PATCH v3] dmaengine: idxd: fix fdev setup failure cleanup in idxd_cdev_open()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] If `ida_alloc()` fails in `idxd_cdev_open()`, the error code is not assigned to `rc`, causing the function to return 0 (success) while leaving `filp->private_data` pointing to a freed context.
--

commit 51406f4c692bf6e1cbab1fe293fc2fda433beb08
Author: Yuho Choi <dbgh9129@gmail.com>

dmaengine: idxd: fix fdev setup failure cleanup in idxd_cdev_open()

This commit fixes a deadlock and use-after-free during file-device setup
failures in idxd_cdev_open(). It moves idxd_wq_get() to occur before
potential failures and adjusts the cleanup path to return directly, leaving
context cleanup to the release callback.

> diff --git a/drivers/dma/idxd/cdev.c b/drivers/dma/idxd/cdev.c
> --- a/drivers/dma/idxd/cdev.c
> +++ b/drivers/dma/idxd/cdev.c
[ ... ]
> @@ -301,13 +302,14 @@ static int idxd_cdev_open(struct inode *inode, struct file *filp)
>  		goto failed_dev_add;
>  	}
>  
> -	idxd_wq_get(wq);
>  	mutex_unlock(&wq->wq_lock);
>  	return 0;
>  
>  failed_dev_add:
>  failed_dev_name:
> +	mutex_unlock(&wq->wq_lock);
>  	put_device(fdev);
> +	return rc;
>  failed_ida:

[Severity: Critical]
This isn't a bug introduced by this patch, but is it possible for rc to be
0 when reaching this label?

Looking at the ida_alloc() call earlier in this function:

    ctx->id = ida_alloc(&file_ida, GFP_KERNEL);
    if (ctx->id < 0) {
        dev_warn(dev, "ida alloc failure\n");
        goto failed_ida;
    }

If ida_alloc() fails, it returns a negative error code to ctx->id, but rc
is not updated and remains 0. The function then jumps to failed_ida,
eventually frees the context, and returns 0.

Since open() returns 0, the VFS layer treats the system call as successful
and returns a valid file descriptor to user space. However,
filp->private_data was already set to the freed ctx earlier in the function.

Could this lead to a use-after-free if subsequent file operations (like
write() or close()) dereference the dangling filp->private_data pointer?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260525141550.1385581-1-dbgh9129@gmail.com?part=1