Re: [PATCH 5.4] filelock: Correct the filelock owner in fcntl_setlk/fcntl_setlk64

[Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>]

On Fri, Aug 16, 2024 at 01:06:27PM +0800, Long Li wrote:
> The locks_remove_posix() function in fcntl_setlk/fcntl_setlk64 is designed
> to reliably remove locks when an fcntl/close race is detected. However, it
> was passing in the wrong filelock owner, it looks like a mistake and
> resulting in a failure to remove locks. More critically, if the lock
> removal fails, it could lead to a uaf issue while traversing the locks.
> 
> This problem occurs only in the 4.19/5.4 stable version.
> 
> Fixes: 4c43ad4ab416 ("filelock: Fix fcntl/close race recovery compat path")
> Fixes: dc2ce1dfceaa ("filelock: Remove locks reliably when fcntl/close race is detected")
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Long Li <leo.lilong@xxxxxxxxxx>
> ---
>  fs/locks.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/locks.c b/fs/locks.c
> index 85c8af53d4eb..cf6ed857664b 100644
> --- a/fs/locks.c
> +++ b/fs/locks.c
> @@ -2542,7 +2542,7 @@ int fcntl_setlk(unsigned int fd, struct file *filp, unsigned int cmd,
>  		f = fcheck(fd);
>  		spin_unlock(&current->files->file_lock);
>  		if (f != filp) {
> -			locks_remove_posix(filp, &current->files);
> +			locks_remove_posix(filp, current->files);

Ick, sorry about this, that was my fault in my backport.

both now queued up, thanks.

greg k-h