From: David Laight <david.laight.linux@gmail.com>
To: Alexei Safin <a.safin@rosa.ru>
Cc: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Eduard Zingerman <eddyz87@gmail.com>, Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@fomichev.me>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>, Yafang Shao <laoar.shao@gmail.com>,
bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
lvc-patches@linuxtesting.org, stable@vger.kernel.org
Subject: Re: [PATCH v2] bpf: hashtab: fix 32-bit overflow in memory usage calculation
Date: Fri, 7 Nov 2025 11:41:27 +0000 [thread overview]
Message-ID: <20251107114127.4e130fb2@pumpkin> (raw)
In-Reply-To: <20251107100310.61478-1-a.safin@rosa.ru>
On Fri, 7 Nov 2025 13:03:05 +0300
Alexei Safin <a.safin@rosa.ru> wrote:
> The intermediate product value_size * num_possible_cpus() is evaluated
> in 32-bit arithmetic and only then promoted to 64 bits. On systems with
> large value_size and many possible CPUs this can overflow and lead to
> an underestimated memory usage.
>
> Found by Linux Verification Center (linuxtesting.org) with SVACE.
That code is insane.
The size being calculated looks like a kernel memory size.
You really don't want to be allocating single structures that exceed 4GB.
David
>
> Fixes: 304849a27b34 ("bpf: hashtab memory usage")
> Cc: stable@vger.kernel.org
> Suggested-by: Yafang Shao <laoar.shao@gmail.com>
> Signed-off-by: Alexei Safin <a.safin@rosa.ru>
> ---
> v2: Promote value_size to u64 at declaration to avoid 32-bit overflow
> in all arithmetic using this variable (suggested by Yafang Shao)
> kernel/bpf/hashtab.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
> index 570e2f723144..1f0add26ba3f 100644
> --- a/kernel/bpf/hashtab.c
> +++ b/kernel/bpf/hashtab.c
> @@ -2252,7 +2252,7 @@ static long bpf_for_each_hash_elem(struct bpf_map *map, bpf_callback_t callback_
> static u64 htab_map_mem_usage(const struct bpf_map *map)
> {
> struct bpf_htab *htab = container_of(map, struct bpf_htab, map);
> - u32 value_size = round_up(htab->map.value_size, 8);
> + u64 value_size = round_up(htab->map.value_size, 8);
> bool prealloc = htab_is_prealloc(htab);
> bool percpu = htab_is_percpu(htab);
> bool lru = htab_is_lru(htab);
next prev parent reply other threads:[~2025-11-07 11:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-07 10:03 [PATCH v2] bpf: hashtab: fix 32-bit overflow in memory usage calculation Alexei Safin
2025-11-07 11:35 ` Yafang Shao
2025-11-07 11:41 ` David Laight [this message]
2025-11-09 3:00 ` Yafang Shao
2025-11-09 8:20 ` Yafang Shao
2025-11-09 11:00 ` Алексей Сафин
2025-11-09 12:10 ` Yafang Shao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251107114127.4e130fb2@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=a.safin@rosa.ru \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=laoar.shao@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lvc-patches@linuxtesting.org \
--cc=martin.lau@linux.dev \
--cc=sdf@fomichev.me \
--cc=song@kernel.org \
--cc=stable@vger.kernel.org \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.