2021-09-19 13:00:01

by Len Baker

[permalink] [raw]
Subject: [PATCH] aio: Prefer struct_size over open coded arithmetic

As noted in the "Deprecated Interfaces, Language Features, Attributes,
and Conventions" documentation [1], size calculations (especially
multiplication) should not be performed in memory allocator (or similar)
function arguments due to the risk of them overflowing. This could lead
to values wrapping around and a smaller allocation being made than the
caller was expecting. Using those allocations could lead to linear
overflows of heap memory and other misbehaviors.

So, use the struct_size() helper to do the arithmetic instead of the
argument "size + size * count" in the kzalloc() function.

[1] https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments

Signed-off-by: Len Baker <[email protected]>
---
fs/aio.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/fs/aio.c b/fs/aio.c
index 51b08ab01dff..c2978c0b872c 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -659,8 +659,7 @@ static int ioctx_add_table(struct kioctx *ctx, struct mm_struct *mm)
new_nr = (table ? table->nr : 1) * 4;
spin_unlock(&mm->ioctx_lock);

- table = kzalloc(sizeof(*table) + sizeof(struct kioctx *) *
- new_nr, GFP_KERNEL);
+ table = kzalloc(struct_size(table, table, new_nr), GFP_KERNEL);
if (!table)
return -ENOMEM;

--
2.25.1


2021-09-21 03:54:16

by Gustavo A. R. Silva

[permalink] [raw]
Subject: Re: [PATCH] aio: Prefer struct_size over open coded arithmetic



On 9/19/21 04:45, Len Baker wrote:
> As noted in the "Deprecated Interfaces, Language Features, Attributes,
> and Conventions" documentation [1], size calculations (especially
> multiplication) should not be performed in memory allocator (or similar)
> function arguments due to the risk of them overflowing. This could lead
> to values wrapping around and a smaller allocation being made than the
> caller was expecting. Using those allocations could lead to linear
> overflows of heap memory and other misbehaviors.
>
> So, use the struct_size() helper to do the arithmetic instead of the
> argument "size + size * count" in the kzalloc() function.
>
> [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments
>
> Signed-off-by: Len Baker <[email protected]>

Reviewed-by: Gustavo A. R. Silva <[email protected]>

Thanks
--
Gustavo

> ---
> fs/aio.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/fs/aio.c b/fs/aio.c
> index 51b08ab01dff..c2978c0b872c 100644
> --- a/fs/aio.c
> +++ b/fs/aio.c
> @@ -659,8 +659,7 @@ static int ioctx_add_table(struct kioctx *ctx, struct mm_struct *mm)
> new_nr = (table ? table->nr : 1) * 4;
> spin_unlock(&mm->ioctx_lock);
>
> - table = kzalloc(sizeof(*table) + sizeof(struct kioctx *) *
> - new_nr, GFP_KERNEL);
> + table = kzalloc(struct_size(table, table, new_nr), GFP_KERNEL);
> if (!table)
> return -ENOMEM;
>
> --
> 2.25.1
>

2021-10-20 23:20:29

by Gustavo A. R. Silva

[permalink] [raw]
Subject: Re: [PATCH] aio: Prefer struct_size over open coded arithmetic

On Mon, Sep 20, 2021 at 07:11:17PM -0500, Gustavo A. R. Silva wrote:
>
>
> On 9/19/21 04:45, Len Baker wrote:
> > As noted in the "Deprecated Interfaces, Language Features, Attributes,
> > and Conventions" documentation [1], size calculations (especially
> > multiplication) should not be performed in memory allocator (or similar)
> > function arguments due to the risk of them overflowing. This could lead
> > to values wrapping around and a smaller allocation being made than the
> > caller was expecting. Using those allocations could lead to linear
> > overflows of heap memory and other misbehaviors.
> >
> > So, use the struct_size() helper to do the arithmetic instead of the
> > argument "size + size * count" in the kzalloc() function.
> >
> > [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments
> >
> > Signed-off-by: Len Baker <[email protected]>
>
> Reviewed-by: Gustavo A. R. Silva <[email protected]>

I'm taking this in my -next tree.

Thanks, Len.
--
Gustavo