From: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>
To: "Shihuang Liu" <shlomojune6@gmail.com>, <bpf@vger.kernel.org>
Cc: <daniel@iogearbox.net>, <andrii@kernel.org>, <eddyz87@gmail.com>,
<memxor@gmail.com>, <martin.lau@linux.dev>, <song@kernel.org>,
<yonghong.song@linux.dev>, <jolsa@kernel.org>,
<emil@etsalapatis.com>, <ihor.solodrai@linux.dev>
Subject: Re: [PATCH] bpf: fix special field check with variable offset access
Date: Sat, 07 Nov 2026 16:58:36 +0000 [thread overview]
Message-ID: <DMP4ZP50NN1A.3CMXK8Y0G0YO2@gmail.com> (raw)
In-Reply-To: <20261107135419.81491-1-shlomojune6@gmail.com>
On Sat, Nov 07, 2026 at 05:54 AM Shihuang Liu <shlomojune6@gmail.com> wrote:
> btf_struct_access() rejects direct access to special fields (kptr,
> spin_lock, list/rbtree nodes, ...) of program allocated objects, but
> for variable offset access the check is done at min_off only, while
> the whole [min_off, max_off] range can be reached at runtime. A read
> leaks the pointer; a write corrupts the refcounted pointer and crashes
> the release path (bpf_obj_free_fields -> bpf_mem_free_rcu).
Not the whole range.
The code at check_variable_offset: keeps the access inside one array.
reg->step has to be a multiple of the element size.
Every access lands on the same member of some element.
btf_repeat_fields() repeats the special fields for every element.
So with BTF from a compiler the check at min_off is enough.
I think it takes hand-made BTF with members that overlap:
struct node {
u64 arr[4]; offset 0, size 32
struct foo __kptr *p; offset 8
};
btf_struct_check_meta() only rejects offsets that go down.
A store to arr[i], i in [0, 3], passes the check at offset 0 and hits p.
Is that how you got there? Explain in commit log.
Also drop "A read leaks the pointer".
check_ptr_to_btf_access() allows these loads with CAP_PERFMON only.
> - if (off < offset + field->size && offset < off + size) {
> + if (min_off < (s64)offset + field->size &&
> + (s64)offset < max_off + size) {
This rejects a prog that loads today:
struct elem { u64 data; struct foo __kptr *p; };
struct node { struct elem arr[4]; struct foo __kptr *q; };
n->arr[i].data = 1; i in [0, 3], step 16
pw-bot: cr
next prev parent reply other threads:[~2026-11-07 16:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-07 13:54 [PATCH] bpf: fix special field check with variable offset access Shihuang Liu
2026-11-07 14:35 ` bot+bpf-ci
2026-11-07 16:58 ` Alexei Starovoitov [this message]
2026-11-08 15:29 ` J4f J4f
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=DMP4ZP50NN1A.3CMXK8Y0G0YO2@gmail.com \
--to=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=ihor.solodrai@linux.dev \
--cc=jolsa@kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=shlomojune6@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