linux-kernel - Re: [PATCH] bpf: Fix excessive memory allocation in stack_map

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: <YqC+WquFukW84W12@kroah.com>
Date:   Wed, 8 Jun 2022 17:20:58 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Yuntao Wang <ytcoode@...il.com>
Cc:     pavel@...x.de, daniel@...earbox.net, linux-kernel@...r.kernel.org,
        sashal@...nel.org, stable@...r.kernel.org
Subject: Re: [PATCH] bpf: Fix excessive memory allocation in stack_map_alloc()

On Wed, Jun 08, 2022 at 10:25:38PM +0800, Yuntao Wang wrote:
> The 'n_buckets * (value_size + sizeof(struct stack_map_bucket))' part of
> the allocated memory for 'smap' is never used, get rid of it.
> 
> Fixes: b936ca643ade ("bpf: rework memlock-based memory accounting for maps")
> Signed-off-by: Yuntao Wang <ytcoode@...il.com>
> Link: https://lore.kernel.org/bpf/20220407130423.798386-1-ytcoode@gmail.com
> ---
> This is the modified version for 5.10, the original patch is:
> 
> [ Upstream commit b45043192b3e481304062938a6561da2ceea46a6 ]
> 
> It would be better if the new patch can be reviewed by someone else.

What is wrong with the version that we have queued up in the 5.10-stable
review queue right now?



> 
>  kernel/bpf/stackmap.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
> index 4575d2d60cb1..54fdcb78ad19 100644
> --- a/kernel/bpf/stackmap.c
> +++ b/kernel/bpf/stackmap.c
> @@ -121,8 +121,8 @@ static struct bpf_map *stack_map_alloc(union bpf_attr *attr)
>  		return ERR_PTR(-E2BIG);
>  
>  	cost = n_buckets * sizeof(struct stack_map_bucket *) + sizeof(*smap);
> -	cost += n_buckets * (value_size + sizeof(struct stack_map_bucket));
> -	err = bpf_map_charge_init(&mem, cost);
> +	err = bpf_map_charge_init(&mem, cost + n_buckets *
> +				  (value_size + sizeof(struct stack_map_bucket)));

This differs from what we have queued up for 5.4.y and 5.10.y, why?
If you are going to modify the upstream version, you need to document in
great detail what you have changed and why you have changed it.

thanks,

greg k-h