lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 13 May 2020 11:56:11 -0600
From:   Shuah Khan <skhan@...uxfoundation.org>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     axboe@...nel.dk, zohar@...ux.vnet.ibm.com, mcgrof@...nel.org,
        keescook@...omium.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: [PATCH v2 2/2] fs: avoid fdput() after failed fdget() in
 kernel_read_file_from_fd()

On 5/12/20 11:49 PM, Al Viro wrote:
> On Tue, May 12, 2020 at 01:43:05PM -0600, Shuah Khan wrote:
>> Fix kernel_read_file_from_fd() to avoid fdput() after a failed fdget().
>> fdput() doesn't do fput() on this file since FDPUT_FPUT isn't set
>> in fd.flags. Fix it anyway since failed fdget() doesn't require
>> a fdput().
>>
>> This was introduced in a commit that added kernel_read_file_from_fd() as
>> a wrapper for the VFS common kernel_read_file().
>>
>> Fixes: b844f0ecbc56 ("vfs: define kernel_copy_file_from_fd()")
>> Signed-off-by: Shuah Khan <skhan@...uxfoundation.org>
>> ---
>>   fs/exec.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/fs/exec.c b/fs/exec.c
>> index 06b4c550af5d..ea24bdce939d 100644
>> --- a/fs/exec.c
>> +++ b/fs/exec.c
>> @@ -1021,8 +1021,8 @@ int kernel_read_file_from_fd(int fd, void **buf, loff_t *size, loff_t max_size,
>>   		goto out;
>>   
>>   	ret = kernel_read_file(f.file, buf, size, max_size, id);
>> -out:
>>   	fdput(f);
>> +out:
>>   	return ret;
> 
> Again, that goto is a pointless obfuscation; just return -EBADF
> and be done with that.
> 

My reasoning is if this routine ends up growing it might be useful
to handle the return this way.

In any case, I will send v3 for both of these patches.

thanks,
-- Shuah

Powered by blists - more mailing lists