linux-kernel - Re: [PATCH] staging/lustre/llite: Use memdup_user() rather than duplicating its implementation

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 linux-cve-announce 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]

Message-ID: <57B98890.7070900@oracle.com>
Date:   Sun, 21 Aug 2016 16:25:12 +0530
From:   Vaishali Thakkar <vaishali.thakkar@...cle.com>
To:     Julia Lawall <julia.lawall@...6.fr>,
        Christophe JAILLET <christophe.jaillet@...adoo.fr>
Cc:     kernel-janitors@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging/lustre/llite: Use memdup_user() rather than
 duplicating its implementation



On Sunday 21 August 2016 04:01 PM, Julia Lawall wrote:
> 
> 
> On Sun, 21 Aug 2016, Christophe JAILLET wrote:
> 
>> Le 21/08/2016 à 11:45, SF Markus Elfring a écrit :
>>> From: Markus Elfring <elfring@...rs.sourceforge.net>
>>> Date: Sun, 21 Aug 2016 11:30:57 +0200
>>>
>>> Reuse existing functionality from memdup_user() instead of keeping
>>> duplicate source code.
>>>
>>> This issue was detected by using the Coccinelle software.
>>>
>>> Signed-off-by: Markus Elfring <elfring@...rs.sourceforge.net>
>>> ---
>>>   drivers/staging/lustre/lustre/llite/dir.c | 12 +++---------
>>>   1 file changed, 3 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/staging/lustre/lustre/llite/dir.c
>>> b/drivers/staging/lustre/lustre/llite/dir.c
>>> index 031c9e4..8b70e42 100644
>>> --- a/drivers/staging/lustre/lustre/llite/dir.c
>>> +++ b/drivers/staging/lustre/lustre/llite/dir.c
>>> @@ -1676,14 +1676,9 @@ out_poll:
>>>   	case LL_IOC_QUOTACTL: {
>>>   		struct if_quotactl *qctl;
>>>   -		qctl = kzalloc(sizeof(*qctl), GFP_NOFS);
>> Same as previously reported in another patch, GFP_NOFS has not the same
>> meaning than GPF_KERNEL.
>> So your proposed clean-up is not 100% equivalent.
>>
>> Are your sure that GPF_KERNEL instead of GFP_NOFS is right in this code?
>>
>> Maybe, the coccinelle check should be tweak to only spot "kzalloc(...,
>> GFP_KERNEL)" allocation?
> 
> To my dim recollection, GFP_NOFS is not actually allowed in a place where
> copy_from_user is being used.  copy_from_user can block due to page
> faults, and GFP_NOFS is used when a certain kind of blocking is not
> allowed.  So if the code really needs GFP_NOFS, then something else is
> wrong.
> 
> The semantic patch intentionally does not specify GFP_KERNEL for this
> reason, ie so that these issues will come up and be discussed.  On the
> ther hand I agree about the GFP_DMA case, since that doesn't relate to
> blocking, as far as I know.  The semantic patch should be updated to not
> make/propose the change in that case.

I think semantic patch should be updated for all possible flags except
GFP_NOFS and GFP_ATOMIC. Because only using these 2 flags with
copy_from_user can cause blocking.

> julia
> 
>>
>>> -		if (!qctl)
>>> -			return -ENOMEM;
>>> -
>>> -		if (copy_from_user(qctl, (void __user *)arg, sizeof(*qctl))) {
>>> -			rc = -EFAULT;
>>> -			goto out_quotactl;
>>> -		}
>>> +		qctl = memdup_user((void __user *)arg, sizeof(*qctl));
>>> +		if (IS_ERR(qctl))
>>> +			return PTR_ERR(qctl);
>>>     		rc = quotactl_ioctl(sbi, qctl);
>>>   @@ -1691,7 +1686,6 @@ out_poll:
>>>   					    sizeof(*qctl)))
>>>   			rc = -EFAULT;
>>>   -out_quotactl:
>>>   		kfree(qctl);
>>>   		return rc;
>>>   	}
>>
>>
>>
>> ---
>> L'absence de virus dans ce courrier électronique a été vérifiée par le
>> logiciel antivirus Avast.
>> https://www.avast.com/antivirus
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
>> the body of a message to majordomo@...r.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 

-- 
Vaishali