From: Masoud Aghasi <maghasi@disroot.org>
To: bpf@vger.kernel.org
Cc: andrii@kernel.org, eddyz87@gmail.com, ast@kernel.org,
daniel@iogearbox.net, memxor@gmail.com, martin.lau@linux.dev,
song@kernel.org, yonghong.song@linux.dev, jolsa@kernel.org,
emil@etsalapatis.com, ihor.solodrai@linux.dev,
john.fastabend@gmail.com, brianvv@google.com,
maghasi@disroot.org
Subject: Re: [PATCH] bpf: Fix u32 overflow issue in map batch operations
Date: Tue, 25 Aug 2026 11:21:18 +0100 [thread overview]
Message-ID: <317cc6ae-eeb6-4de1-b986-cdbaa16bcc2f@disroot.org> (raw)
In-Reply-To: <20260824114216.6CFFE1F000E9@smtp.kernel.org>
On 24/08/2026 12:42, sashiko-bot@kernel.org wrote:
>
> [Severity: High]
> This is a pre-existing issue, but does key_size * bucket_cnt or
> value_size * bucket_cnt also need a size_t cast here?
>
> If value_size * bucket_cnt exceeds 4GB, the 32-bit integer overflow would
> truncate the length argument to copy_to_user() in
> __htab_map_lookup_and_delete_batch(), causing it to copy less data than
> expected. This could result in silent data loss since the elements are
> permanently deleted from the kernel map, while the syscall falsely returns
> success.
>
>> value_size * bucket_cnt))) {
>> ret = -EFAULT;
>> goto after_loop;
>
Yes, I was able to produce "bucket_cnt > 1024" using a map with
BPF_F_ZERO_SEED flag set, 64bit key_size and generating an special
sequence of keys using the below code:
```c
int counter = 0;
__u64 keys[1025];
for (unsigned long i = 0x10000; i <= 0xffffffffffffffff; i++) {
if ((jhash2((__u32 *)&i, 2, 0) & (0x10000 - 1)) == 0) {
keys[counter] = i;
counter++;
if(counter > 1024)
break;
}
}
```
So the overflow is possible and I will include the fix in the patch v2.
next prev parent reply other threads:[~2026-08-25 10:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-24 11:31 [PATCH] bpf: Fix u32 overflow issue in map batch operations Masoud Aghasi
2026-08-24 11:42 ` sashiko-bot
2026-08-25 10:21 ` Masoud Aghasi [this message]
2026-09-02 20:44 ` [PATCH v2] " Masoud Aghasi
2026-09-02 21:50 ` bot+bpf-ci
2026-09-03 8:27 ` [PATCH v3] " Masoud Aghasi
2026-09-03 8:45 ` sashiko-bot
2026-09-03 12:31 ` Masoud Aghasi
2026-09-04 4:45 ` Alexei Starovoitov
2026-08-24 12:17 ` [PATCH] " bot+bpf-ci
2026-08-24 19:15 ` Masoud Aghasi
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=317cc6ae-eeb6-4de1-b986-cdbaa16bcc2f@disroot.org \
--to=maghasi@disroot.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brianvv@google.com \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=ihor.solodrai@linux.dev \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=song@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox