From: Long Li <leo.lilong@xxxxxxxxxx> 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: a561145f3ae9 ("filelock: Fix fcntl/close race recovery compat path") Fixes: d30ff3304083 ("filelock: Remove locks reliably when fcntl/close race is detected") Cc: stable@xxxxxxxxxxxxxxx Signed-off-by: Long Li <leo.lilong@xxxxxxxxxx> Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> --- fs/locks.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/fs/locks.c +++ b/fs/locks.c @@ -2313,7 +2313,7 @@ int fcntl_setlk(unsigned int fd, struct f = fcheck(fd); spin_unlock(¤t->files->file_lock); if (f != filp) { - locks_remove_posix(filp, ¤t->files); + locks_remove_posix(filp, current->files); error = -EBADF; } } @@ -2443,7 +2443,7 @@ int fcntl_setlk64(unsigned int fd, struc f = fcheck(fd); spin_unlock(¤t->files->file_lock); if (f != filp) { - locks_remove_posix(filp, ¤t->files); + locks_remove_posix(filp, current->files); error = -EBADF; } } Patches currently in stable-queue which might be from leo.lilong@xxxxxxxxxx are queue-4.19/filelock-correct-the-filelock-owner-in-fcntl_setlk-fcntl_setlk64.patch