From: sashiko-bot@kernel.org
To: "Anastasios Papagiannis" <tasos.papagiannnis@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v3 2/7] bpf: Add user memory access kfuncs for mm_struct
Date: Mon, 31 Aug 2026 10:01:52 +0000 [thread overview]
Message-ID: <20260831100153.60EF21F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260831092305.42062-3-tasos.papagiannnis@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The `dst` arguments in `bpf_copy_from_user_mm` and `bpf_copy_from_user_mm_str` lack the `__uninit` suffix, causing the verifier to reject uninitialized stack memory and forcing unnecessary zero-initialization.
--
commit 064bec09b54d9a7638a0865baa943bd0e6467f30
Author: Anastasios Papagiannis <tasos.papagiannnis@gmail.com>
bpf: Add user memory access kfuncs for mm_struct
This commit adds bpf_copy_from_user_mm() and bpf_copy_from_user_mm_str()
kfuncs to allow BPF programs to access trusted address spaces not associated
with a task_struct. It also updates existing task-based user memory access
helpers to use these new functions.
> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> index b3cc5c8fc8756..19c01aa734ae1 100644
> --- a/kernel/bpf/helpers.c
> +++ b/kernel/bpf/helpers.c
[ ... ]
> +__bpf_kfunc int bpf_copy_from_user_mm(void *dst, u32 dst__sz,
> + const void __user *unsafe_ptr__ign,
> + struct mm_struct *mm, u64 flags)
> +{
[Severity: Low]
Should the dst parameter be named dst__uninit here?
Without the __uninit suffix, the BPF verifier natively treats void pointer
kfunc parameters as ARG_PTR_TO_MEM. This forces BPF programs to redundantly
zero-initialize their buffers before calling these sleepable kfuncs, degrading
usability and performance compared to the older bpf_copy_from_user_task helper.
> + int ret;
> +
> + if (unlikely(flags))
> + return -EINVAL;
[Severity: Low]
If the __uninit suffix is added, the verifier will assume the buffer is
initialized upon return. Without clearing the buffer on this early path,
could this allow a BPF program to read uninitialized kernel stack memory?
[ ... ]
> +__bpf_kfunc int bpf_copy_from_user_mm_str(void *dst, u32 dst__sz,
> + const void __user *unsafe_ptr__ign,
> + struct mm_struct *mm, u64 flags)
> {
> int ret;
[Severity: Low]
Similar to bpf_copy_from_user_mm above, does this dst parameter also need the
__uninit suffix to avoid forcing BPF programs to pre-initialize the memory?
If it does, the early flags check in this function would also need to zero
the buffer before returning -EINVAL to avoid leaking uninitialized memory.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260831092305.42062-1-tasos.papagiannnis@gmail.com?part=2
next prev parent reply other threads:[~2026-08-31 10:01 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-31 9:22 [PATCH bpf-next v3 0/7] bpf: Add user memory access kfuncs for mm_struct Anastasios Papagiannis
2026-08-31 9:22 ` [PATCH bpf-next v3 1/7] mm: Add copy_remote_mm_str() Anastasios Papagiannis
2026-08-31 9:23 ` [PATCH bpf-next v3 2/7] bpf: Add user memory access kfuncs for mm_struct Anastasios Papagiannis
2026-08-31 10:01 ` sashiko-bot [this message]
2026-08-31 10:43 ` bot+bpf-ci
2026-08-31 9:23 ` [PATCH bpf-next v3 3/7] exec: Clear bprm->mm before dropping its reference Anastasios Papagiannis
2026-08-31 10:25 ` sashiko-bot
2026-08-31 10:30 ` bot+bpf-ci
2026-09-01 3:19 ` sun jian
2026-09-01 8:56 ` sun jian
2026-08-31 9:23 ` [PATCH bpf-next v3 4/7] bpf: Allow reads through trusted-or-null BTF pointers Anastasios Papagiannis
2026-08-31 10:43 ` bot+bpf-ci
2026-08-31 9:23 ` [PATCH bpf-next v3 5/7] selftests/bpf: Cover trusted-or-null BTF pointer reads Anastasios Papagiannis
2026-08-31 10:43 ` bot+bpf-ci
2026-08-31 10:55 ` sashiko-bot
2026-08-31 9:23 ` [PATCH bpf-next v3 6/7] bpf: Mark linux_binprm->mm as trusted-or-null Anastasios Papagiannis
2026-08-31 10:43 ` bot+bpf-ci
2026-09-01 3:50 ` sun jian
2026-08-31 9:23 ` [PATCH bpf-next v3 7/7] selftests/bpf: Test mm_struct user memory kfuncs with linux_binprm Anastasios Papagiannis
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=20260831100153.60EF21F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=tasos.papagiannnis@gmail.com \
/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.