BPF List
 help / color / mirror / Atom feed
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

  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