From: sashiko-bot@kernel.org
To: "Amery Hung" <ameryhung@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v1 2/2] bpf: Zero kfunc arg meta before error paths can read it
Date: Wed, 15 Jul 2026 17:38:53 +0000 [thread overview]
Message-ID: <20260715173853.886C81F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260715172127.2416388-3-ameryhung@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] BPF kfuncs bpf_mem_cgroup_memory_events and bpf_mem_cgroup_vm_events do not handle negative enum values, bypassing bounds checks and allowing out-of-bounds array reads.
--
--- Patch [2]: [PATCH bpf-next v1 2/2] bpf: Zero kfunc arg meta before error paths can read it ---
commit 53f60dae3990fbb436a03cb878e7564339ccd1e9
Author: Amery Hung <ameryhung@gmail.com>
bpf: Zero kfunc arg meta before error paths can read it
check_kfunc_call() reads meta.func_name when bpf_fetch_kfunc_arg_meta()
returns -EACCES, but that error can come from fetch_kfunc_meta() (e.g.
fd_array_get_btf() rejecting BTF binding for a signed program) before
meta is memset(), leaving it uninitialized and risking a garbage deref
in verbose().
Move the memset() to the start of bpf_fetch_kfunc_arg_meta() so meta is
zeroed on every error return. The intended "not allowed" -EACCES path
still sets func_name first, so its message is unchanged.
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index c87e5fec5a857..ddfa4f57016b7 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
[ ... ]
[Severity: High]
This isn't a bug introduced by this patch, but this is a pre-existing issue.
Do the bounds checks in bpf_mem_cgroup_memory_events() and
bpf_mem_cgroup_vm_events() properly handle negative values?
Since enums evaluate to signed integers in C, and the BPF verifier does
not enforce enum ranges, a BPF program could pass a negative value to
bpf_mem_cgroup_memory_events() in mm/bpf_memcontrol.c:
if (unlikely(event >= MEMCG_NR_MEMORY_EVENTS))
return (unsigned long)-1;
return atomic_long_read(&memcg->memory_events[event]);
For a negative value, the bounds check above evaluates to false, which
allows an out-of-bounds read on the memory_events array.
Can a similar out-of-bounds read happen in bpf_mem_cgroup_vm_events()?
if (unlikely(!memcg_vm_event_item_valid(event)))
return (unsigned long)-1;
return memcg_events(memcg, event);
The validation routine in mm/memcontrol.c uses the same signed comparison:
bool memcg_vm_event_item_valid(enum vm_event_item idx)
{
if (idx >= NR_VM_EVENT_ITEMS)
return false;
return !BAD_STAT_IDX(memcg_events_index(idx));
}
This allows negative index values to reach memcg_events_index():
static inline int memcg_events_index(enum vm_event_item idx)
{
return mem_cgroup_events_index[idx];
}
Could this allow a BPF program to read arbitrary out-of-bounds kernel memory?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260715172127.2416388-1-ameryhung@gmail.com?part=2
next prev parent reply other threads:[~2026-07-15 17:38 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-15 17:21 [PATCH bpf-next v1 0/2] Fix leftover issues of the unify bpf_call_arg_meta patchset Amery Hung
2026-07-15 17:21 ` [PATCH bpf-next v1 1/2] bpf: Disable raw mdoe for bloom filter map_peek Amery Hung
2026-07-15 17:38 ` sashiko-bot
2026-07-15 18:07 ` Kumar Kartikeya Dwivedi
2026-07-15 18:06 ` bot+bpf-ci
2026-07-15 18:18 ` Kumar Kartikeya Dwivedi
2026-07-15 17:21 ` [PATCH bpf-next v1 2/2] bpf: Zero kfunc arg meta before error paths can read it Amery Hung
2026-07-15 17:38 ` sashiko-bot [this message]
2026-07-15 18:11 ` Kumar Kartikeya Dwivedi
2026-07-15 18:06 ` bot+bpf-ci
2026-07-15 18:09 ` Kumar Kartikeya Dwivedi
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=20260715173853.886C81F00A3D@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=ameryhung@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=sashiko-reviews@lists.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