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

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

[Long Li]

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@vger.kernel.org
Signed-off-by: Long Li <leo.lilong@huawei.com>
---
 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);
 			error = -EBADF;
 		}
 	}
@@ -2672,7 +2672,7 @@ int fcntl_setlk64(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);
 			error = -EBADF;
 		}
 	}
-- 
2.39.2

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

[Greg KH]

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@vger.kernel.org
> Signed-off-by: Long Li <leo.lilong@huawei.com>
> ---
>  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