Re: [PATCH] fsi:fsi-sbefifo: Fix possible concurrency use-after-free bugs in sbefifo_user_release

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Wed, 2018-12-26 at 21:56 +0800, Jia-Ju Bai wrote:
> In drivers/fsi/fsi-sbefifo.c, the functions sbefifo_user_release(), 
> sbefifo_user_read() and sbefifo_user_write() may be concurrently executed.

So after refreshing my mind, looking at the code and talking with Al, I
really dont' see what race you are trying to fix here.

read/write should never be concurrent with release for a given file and
the stuff we are protecting here is local to the file instance.

Do you have an actual problem you observed ?

Cheers,
Ben.

> sbefifo_user_release()
>   sbefifo_release_command()
>     vfree(user->pending_cmd);
> 
> sbefifo_user_read()
>   mutex_lock();
>   rc = __sbefifo_submit(sbefifo, user->pending_cmd, ...);
> 
> sbefifo_user_write()
>   mutex_lock();
>   user->pending_cmd = user->cmd_page;
>   user->pending_cmd = vmalloc(len);
> 
> Thus, possible concurrency use-after-free bugs may occur in
> sbefifo_user_release().
> 
> To fix these bugs, the calls to mutex_lock() and mutex_unlock() are
> added in sbefifo_user_release().
> 
> 
> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
> ---
>  drivers/fsi/fsi-sbefifo.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/fsi/fsi-sbefifo.c b/drivers/fsi/fsi-sbefifo.c
> index d92f5b87c251..e278a9014b8f 100644
> --- a/drivers/fsi/fsi-sbefifo.c
> +++ b/drivers/fsi/fsi-sbefifo.c
> @@ -900,8 +900,10 @@ static int sbefifo_user_release(struct inode *inode, struct file *file)
>  	if (!user)
>  		return -EINVAL;
>  
> +	mutex_lock(&user->file_lock);
>  	sbefifo_release_command(user);
>  	free_page((unsigned long)user->cmd_page);
> +	mutex_unlock(&user->file_lock);
>  	kfree(user);
>  
>  	return 0;