From: sashiko-bot@kernel.org
To: "Suchit Karunakaran" <suchitkarunakaran@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH v2] bpf: add diagnostics for rejected memory and map accesses
Date: Sun, 27 Sep 2026 19:50:59 +0000 [thread overview]
Message-ID: <20260927195100.6F2D31F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260927194205.125086-1-suchitkarunakaran@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] bpf: missing diagnostics for some read-only memory writes
--
commit 184c7fe51457fa3d0ba8959d5aae6f21fcf5effc
Author: Suchit Karunakaran <suchitkarunakaran@gmail.com>
bpf: add diagnostics for rejected memory and map accesses
Emit structured verifier diagnostics when BPF programs are rejected for
unsupported or prohibited memory operations. Cover sign-extending arena
loads without JIT support, read/write access restrictions on maps, writes
through read-only pointers, direct packet writes, and modifying helpers
used with BPF_F_RDONLY_PROG.
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -6449,6 +6459,10 @@ static int check_mem_access(struct bpf_verifier_env *env, int insn_idx, struct b
> if (t == BPF_WRITE && rdonly_mem) {
> verbose(env, "%s cannot write into %s\n",
> reg_arg_name(env, argno), reg_type_str(env, reg->type));
> + bpf_diag_policy(env, insn_idx, "memory write",
> + bpf_diag_fmt(env, "%s points to read-only memory",
> + reg_arg_name(env, argno)),
> + "Use a writable destination, or copy the data into a writable buffer before modifying it.");
> return -EACCES;
> }
[ ... ]
> } else if (type_is_sk_pointer(reg->type)) {
> if (t == BPF_WRITE) {
> verbose(env, "%s cannot write into %s\n",
> reg_arg_name(env, argno), reg_type_str(env, reg->type));
> return -EACCES;
> }
[Severity: Medium]
Since the commit message mentions adding diagnostics for writes through
read-only pointers, should bpf_diag_policy() also be called here for
direct writes to read-only socket pointers in check_mem_access()?
[ ... ]
> } else if (base_type(reg->type) == PTR_TO_BUF &&
> !type_may_be_null(reg->type)) {
> bool rdonly_mem = type_is_rdonly_mem(reg->type);
> u32 *max_access;
>
> if (rdonly_mem) {
> if (t == BPF_WRITE) {
> verbose(env, "%s cannot write into %s\n",
> reg_arg_name(env, argno), reg_type_str(env, reg->type));
> return -EACCES;
> }
[Severity: Medium]
Does this direct write to a read-only PTR_TO_BUF also need the new
bpf_diag_policy() diagnostic, similar to how it was added for
PTR_TO_MEM earlier in check_mem_access()?
[ ... ]
> @@ -7061,6 +7061,15 @@ static int check_helper_mem_access(struct bpf_verifier_env *env, int regno,
[ ... ]
> case PTR_TO_MEM:
> if (type_is_rdonly_mem(reg->type)) {
> if (access_type == BPF_WRITE) {
> verbose(env, "%s cannot write into %s\n",
> reg_arg_name(env, argno), reg_type_str(env, reg->type));
> return -EACCES;
> }
> }
[Severity: Medium]
If a BPF program passes a read-only PTR_TO_MEM to a helper function that
expects a writable buffer, the access is rejected here in
check_helper_mem_access(). Should this path also emit the structured
diagnostic?
> return check_mem_region_access(env, reg, argno, 0,
> access_size, reg->mem_size,
> zero_size_allowed);
> case PTR_TO_BUF:
> if (type_is_rdonly_mem(reg->type)) {
> if (access_type == BPF_WRITE) {
> verbose(env, "%s cannot write into %s\n",
> reg_arg_name(env, argno), reg_type_str(env, reg->type));
> return -EACCES;
> }
[Severity: Medium]
Similarly, does the rejection of helper function writes to read-only
PTR_TO_BUF pointers in check_helper_mem_access() need a
bpf_diag_policy() call?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260927194205.125086-1-suchitkarunakaran@gmail.com?part=1
next prev parent reply other threads:[~2026-09-27 19:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-27 19:42 [PATCH v2] bpf: add diagnostics for rejected memory and map accesses Suchit Karunakaran
2026-09-27 19:50 ` sashiko-bot [this message]
2026-09-28 7:42 ` Alexei Starovoitov
2026-09-28 10:04 ` Suchit Karunakaran
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=20260927195100.6F2D31F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=suchitkarunakaran@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.