In replace_fd(), the function acquires files->file_lock but then has
two return paths that don't release the lock:
- When do_dup2() fails (returns negative error)
- When do_dup2() succeeds (returns 0)

Both of these paths return directly without unlocking files->file_lock,
causing a lock leak and potential deadlock.

Fix this by making both error and success paths go through the
out_unlock label to ensure the lock is always released.

Fixes: 708c04a5c2b7 ("fs: always return zero on success from replace_fd()")
Cc: stable@vger.kernel.org
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
---
 fs/file.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/fs/file.c b/fs/file.c
index 2c81c0b162d0..d0f019fb0568 100644
--- a/fs/file.c
+++ b/fs/file.c
@@ -1361,8 +1361,7 @@ int replace_fd(unsigned fd, struct file *file, unsigned flags)
 		goto out_unlock;
 	err = do_dup2(files, file, fd, flags);
 	if (err < 0)
-		return err;
-	return 0;
+		goto out_unlock;
 
 out_unlock:
 	spin_unlock(&files->file_lock);
-- 
2.25.1

On Thu, May 21, 2026 at 03:49:34PM +0800, Hongling Zeng wrote:
> In replace_fd(), the function acquires files->file_lock but then has
> two return paths that don't release the lock:
> - When do_dup2() fails (returns negative error)
> - When do_dup2() succeeds (returns 0)
> 
> Both of these paths return directly without unlocking files->file_lock,
> causing a lock leak and potential deadlock.
> 
> Fix this by making both error and success paths go through the
> out_unlock label to ensure the lock is always released.

do_dup2 always releases the lock regardless of return value, so this
patch cannot be correct.

that aside, there is another consumer which would also need patching if
the issue was real

> 
> Fixes: 708c04a5c2b7 ("fs: always return zero on success from replace_fd()")
> Cc: stable@vger.kernel.org
> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
> ---
>  fs/file.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/fs/file.c b/fs/file.c
> index 2c81c0b162d0..d0f019fb0568 100644
> --- a/fs/file.c
> +++ b/fs/file.c
> @@ -1361,8 +1361,7 @@ int replace_fd(unsigned fd, struct file *file, unsigned flags)
>  		goto out_unlock;
>  	err = do_dup2(files, file, fd, flags);
>  	if (err < 0)
> -		return err;
> -	return 0;
> +		goto out_unlock;
>  
>  out_unlock:
>  	spin_unlock(&files->file_lock);
> -- 
> 2.25.1
>

On Thu, May 21, 2026 at 04:45:28PM +0200, Mateusz Guzik wrote:
> On Thu, May 21, 2026 at 03:49:34PM +0800, Hongling Zeng wrote:
> > In replace_fd(), the function acquires files->file_lock but then has
> > two return paths that don't release the lock:
> > - When do_dup2() fails (returns negative error)
> > - When do_dup2() succeeds (returns 0)
> > 
> > Both of these paths return directly without unlocking files->file_lock,
> > causing a lock leak and potential deadlock.
> > 
> > Fix this by making both error and success paths go through the
> > out_unlock label to ensure the lock is always released.
> 
> do_dup2 always releases the lock regardless of return value, so this
> patch cannot be correct.

I mean, also:

static int do_dup2(struct files_struct *files,
        struct file *file, unsigned fd, unsigned flags)
__releases(&files->file_lock)

it's literally in the annotation... and if that had been a bug it would
be very very noticable very very quickly...

   You're right - I missed the __releases(&files->file_lock) annotation
   on do_dup2(). My patch would cause a double-unlock bug.

   Thanks for the correction. I'll verify warnings more carefully next
time.

   Sorry for the noise.

   Hongling
在 2026年05月21日 22:45, Mateusz Guzik 写道:
> On Thu, May 21, 2026 at 03:49:34PM +0800, Hongling Zeng wrote:
>> In replace_fd(), the function acquires files->file_lock but then has
>> two return paths that don't release the lock:
>> - When do_dup2() fails (returns negative error)
>> - When do_dup2() succeeds (returns 0)
>>
>> Both of these paths return directly without unlocking files->file_lock,
>> causing a lock leak and potential deadlock.
>>
>> Fix this by making both error and success paths go through the
>> out_unlock label to ensure the lock is always released.
> do_dup2 always releases the lock regardless of return value, so this
> patch cannot be correct.
>
> that aside, there is another consumer which would also need patching if
> the issue was real
>
>> Fixes: 708c04a5c2b7 ("fs: always return zero on success from replace_fd()")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
>> ---
>>   fs/file.c | 3 +--
>>   1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/fs/file.c b/fs/file.c
>> index 2c81c0b162d0..d0f019fb0568 100644
>> --- a/fs/file.c
>> +++ b/fs/file.c
>> @@ -1361,8 +1361,7 @@ int replace_fd(unsigned fd, struct file *file, unsigned flags)
>>   		goto out_unlock;
>>   	err = do_dup2(files, file, fd, flags);
>>   	if (err < 0)
>> -		return err;
>> -	return 0;
>> +		goto out_unlock;
>>   
>>   out_unlock:
>>   	spin_unlock(&files->file_lock);
>> -- 
>> 2.25.1
>>