[PATCH] arm: sys_oabi-compat: Use kmalloc_array() in two functions

[PATCH] arm: sys_oabi-compat: Use kmalloc_array() in two functions

[SF Markus Elfring]

From: Markus Elfring <elfring@users.sourceforge.net>
Date: Thu, 25 Aug 2016 17:45:23 +0200

Multiplications for the size determination of memory allocations
indicated that array data structures should be processed.
Thus use the corresponding function "kmalloc_array".

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 arch/arm/kernel/sys_oabi-compat.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kernel/sys_oabi-compat.c b/arch/arm/kernel/sys_oabi-compat.c
index 5f221ac..e624db9 100644
--- a/arch/arm/kernel/sys_oabi-compat.c
+++ b/arch/arm/kernel/sys_oabi-compat.c
@@ -285,7 +285,7 @@ asmlinkage long sys_oabi_epoll_wait(int epfd,
 		return -EINVAL;
 	if (!access_ok(VERIFY_WRITE, events, sizeof(*events) * maxevents))
 		return -EFAULT;
-	kbuf = kmalloc(sizeof(*kbuf) * maxevents, GFP_KERNEL);
+	kbuf = kmalloc_array(maxevents, sizeof(*kbuf), GFP_KERNEL);
 	if (!kbuf)
 		return -ENOMEM;
 	fs = get_fs();
@@ -323,7 +323,7 @@ asmlinkage long sys_oabi_semtimedop(int semid,
 		return -EINVAL;
 	if (!access_ok(VERIFY_READ, tsops, sizeof(*tsops) * nsops))
 		return -EFAULT;
-	sops = kmalloc(sizeof(*sops) * nsops, GFP_KERNEL);
+	sops = kmalloc_array(nsops, sizeof(*sops), GFP_KERNEL);
 	if (!sops)
 		return -ENOMEM;
 	err = 0;
-- 
2.9.3

[PATCH] arm: sys_oabi-compat: Use kmalloc_array() in two functions

[Nicolas Pitre]

On Thu, 25 Aug 2016, SF Markus Elfring wrote:

> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Thu, 25 Aug 2016 17:45:23 +0200
> 
> Multiplications for the size determination of memory allocations
> indicated that array data structures should be processed.
> Thus use the corresponding function "kmalloc_array".
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>

The use of kmalloc_array() introduces a duplicate of the size capping 
check that already exists in the code.  However it seems that gcc is 
smart enough to figure that out and doesn't emit it twice.

Note that I'm not implying that the existing check should be removed if 
this patch is applied though. Having it there makes the code clearer. 
But if this patch makes a Coccinelle script happier then ...

Acked-by: Nicolas Pitre <nico@linaro.org>

> ---
>  arch/arm/kernel/sys_oabi-compat.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/kernel/sys_oabi-compat.c b/arch/arm/kernel/sys_oabi-compat.c
> index 5f221ac..e624db9 100644
> --- a/arch/arm/kernel/sys_oabi-compat.c
> +++ b/arch/arm/kernel/sys_oabi-compat.c
> @@ -285,7 +285,7 @@ asmlinkage long sys_oabi_epoll_wait(int epfd,
>  		return -EINVAL;
>  	if (!access_ok(VERIFY_WRITE, events, sizeof(*events) * maxevents))
>  		return -EFAULT;
> -	kbuf = kmalloc(sizeof(*kbuf) * maxevents, GFP_KERNEL);
> +	kbuf = kmalloc_array(maxevents, sizeof(*kbuf), GFP_KERNEL);
>  	if (!kbuf)
>  		return -ENOMEM;
>  	fs = get_fs();
> @@ -323,7 +323,7 @@ asmlinkage long sys_oabi_semtimedop(int semid,
>  		return -EINVAL;
>  	if (!access_ok(VERIFY_READ, tsops, sizeof(*tsops) * nsops))
>  		return -EFAULT;
> -	sops = kmalloc(sizeof(*sops) * nsops, GFP_KERNEL);
> +	sops = kmalloc_array(nsops, sizeof(*sops), GFP_KERNEL);
>  	if (!sops)
>  		return -ENOMEM;
>  	err = 0;
> -- 
> 2.9.3
> 
> 

[PATCH] arm: sys_oabi-compat: Use kmalloc_array() in two functions

[Russell King - ARM Linux]

On Thu, Aug 25, 2016 at 05:50:36PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Thu, 25 Aug 2016 17:45:23 +0200
> 
> Multiplications for the size determination of memory allocations
> indicated that array data structures should be processed.

I'm afraid the above comment doesn't mean much to me, can you rephrase?
Maybe:

"Multiplications for kmalloc size arguments are liable to overflow,
potentially causing a potential security issue.  Using kmalloc_array()
allows the overflow to be caught and the allocation failed.  Switch
these callsites to kmalloc_array()."

> Thus use the corresponding function "kmalloc_array".
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
>  arch/arm/kernel/sys_oabi-compat.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/kernel/sys_oabi-compat.c b/arch/arm/kernel/sys_oabi-compat.c
> index 5f221ac..e624db9 100644
> --- a/arch/arm/kernel/sys_oabi-compat.c
> +++ b/arch/arm/kernel/sys_oabi-compat.c
> @@ -285,7 +285,7 @@ asmlinkage long sys_oabi_epoll_wait(int epfd,
>  		return -EINVAL;
>  	if (!access_ok(VERIFY_WRITE, events, sizeof(*events) * maxevents))
>  		return -EFAULT;
> -	kbuf = kmalloc(sizeof(*kbuf) * maxevents, GFP_KERNEL);
> +	kbuf = kmalloc_array(maxevents, sizeof(*kbuf), GFP_KERNEL);

kmalloc_array() here actually buys us no additional safety at either
of the callsites in your patch - we need to have carefully checked
the values to ensure they don't overflow prior to the kmalloc for
other reasons.  That's probably something that should be noted in
the commit message too, so reviewers have the confidence that you're
not blindly changing everything...

Thanks.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH] arm: sys_oabi-compat: Use kmalloc_array() in two functions

[SF Markus Elfring]

>> Multiplications for the size determination of memory allocations
>> indicated that array data structures should be processed.
> 
> I'm afraid the above comment doesn't mean much to me, can you rephrase?

Yes, of course.

How verbose should the explanation for this update suggestion become?


> Maybe:
> 
> "Multiplications for kmalloc size arguments are liable to overflow,
> potentially causing a potential security issue.  Using kmalloc_array()
> allows the overflow to be caught and the allocation failed.  Switch
> these callsites to kmalloc_array()."

Thanks for your wording variant.


>> @@ -285,7 +285,7 @@ asmlinkage long sys_oabi_epoll_wait(int epfd,
>>  		return -EINVAL;
>>  	if (!access_ok(VERIFY_WRITE, events, sizeof(*events) * maxevents))
>>  		return -EFAULT;
>> -	kbuf = kmalloc(sizeof(*kbuf) * maxevents, GFP_KERNEL);
>> +	kbuf = kmalloc_array(maxevents, sizeof(*kbuf), GFP_KERNEL);
> 
> kmalloc_array() here actually buys us no additional safety at either
> of the callsites in your patch

Can this inline function apply a few sanity checks in a consistent way?
http://lxr.free-electrons.com/source/include/linux/slab.h#L564


> - we need to have carefully checked the values to ensure
> they don't overflow prior to the kmalloc for other reasons.

Are there any more constraints to consider?


> That's probably something that should be noted in the commit message too,
> so reviewers have the confidence that you're not blindly changing everything...

I imagine that a few contributors can get mixed feelings from a bunch
of my recent patches. There is a significant patch number in the works
for various Linux software modules.

Regards,
Markus

[PATCH] arm: sys_oabi-compat: Use kmalloc_array() in two functions

[Russell King - ARM Linux]

On Fri, Aug 26, 2016 at 03:22:29PM +0200, SF Markus Elfring wrote:
> >> Multiplications for the size determination of memory allocations
> >> indicated that array data structures should be processed.
> > 
> > I'm afraid the above comment doesn't mean much to me, can you rephrase?
> 
> Yes, of course.
> 
> How verbose should the explanation for this update suggestion become?

It should at least make basic English sense.  I'm afraid the above
doesn't convey any meaning what so ever, at least to me.  It doesn't
matter how many times I read it, I still end up wondering "wtf is
this trying to tell me?"

A commit message which doesn't convey any meaning is totally useless.
The commit message is there to describe the change not just for the
present, but for years into the future.  It _has_ to be meaningful
and it _has_ to make sense.

> >> @@ -285,7 +285,7 @@ asmlinkage long sys_oabi_epoll_wait(int epfd,
> >>  		return -EINVAL;
> >>  	if (!access_ok(VERIFY_WRITE, events, sizeof(*events) * maxevents))
> >>  		return -EFAULT;
> >> -	kbuf = kmalloc(sizeof(*kbuf) * maxevents, GFP_KERNEL);
> >> +	kbuf = kmalloc_array(maxevents, sizeof(*kbuf), GFP_KERNEL);
> > 
> > kmalloc_array() here actually buys us no additional safety at either
> > of the callsites in your patch
> 
> Can this inline function apply a few sanity checks in a consistent way?
> http://lxr.free-electrons.com/source/include/linux/slab.h#L564

What do you mean "a consistent way" ?  This function is already checking
in this way:

asmlinkage long sys_oabi_epoll_wait(int epfd,
                                    struct oabi_epoll_event __user *events,
                                    int maxevents, int timeout)

        if (maxevents <= 0 ||
                        maxevents > (INT_MAX/sizeof(*kbuf)) ||
                        maxevents > (INT_MAX/sizeof(*events)))
                return -EINVAL;

Do you mean doing something like:

static inline bool array_size_valid(int num, int size)
{
	return num >= 0 && size && num > SIZE_MAX / size;
}

with the above becoming:

	if (!max_events ||
	    !array_size_valid(max_events, sizeof(*kbuf)) ||
	    !array_size_valid(max_events, sizeof(*events)))
		return -EINVAL;

then maybe - but notice that this is using "int" arguments (which can
be negative) as opposed to kmalloc_array() which takes size_t arguments.
So we can't have one helper that fits both kmalloc_array() and this
case - you're talking about creating a specific helper for these cases.

> > - we need to have carefully checked the values to ensure
> > they don't overflow prior to the kmalloc for other reasons.
> 
> Are there any more constraints to consider?

For these functions, I don't think so.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

arm: sys_oabi-compat: Use kmalloc_array() in two functions

[SF Markus Elfring]

> It should at least make basic English sense.  I'm afraid the above
> doesn't convey any meaning what so ever, at least to me.  It doesn't
> matter how many times I read it, I still end up wondering "wtf is
> this trying to tell me?"

I have started to look a bit more on the usage of the following
function pairs in some Linux source files.

kmalloc() ? kmalloc_array()
kzalloc() ? kcalloc()

Can such combinations be extended anyhow?


Some update candidates can be found for this use case in several
software areas.

Regards,
Markus