All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kumar Kartikeya Dwivedi" <memxor@gmail.com>
To: "Ning Ding" <dingning04@gmail.com>
Cc: <bpf@vger.kernel.org>, <ast@kernel.org>, <daniel@iogearbox.net>,
	<andrii@kernel.org>, <eddyz87@gmail.com>, <martin.lau@linux.dev>,
	<davem@davemloft.net>, <greg@kroah.com>
Subject: Re: [PATCH bpf v2 2/2] bpf: Reject untrusted pointers in refcount_acquire
Date: Mon, 03 Aug 2026 09:21:56 +0200	[thread overview]
Message-ID: <DKF4LVGKEKE2.2LUROK1TAUGZ0@gmail.com> (raw)
In-Reply-To: <CAJP4iuskVz4RUrXKcnNhcAwMwcNjCP-Pzpc6=HqfWoDpHKWgWA@mail.gmail.com>

On Mon Aug 3, 2026 at 9:10 AM CEST, Ning Ding wrote:
>> It will work, you can test it yourself. Reads on PTR_UNTRUSTED is fine, it gets
>> handled by the BPF_PROBE_MEM loads, which handle use-after-free safely.
>
> But if we apply the one-line change to type_is_ptr_alloc_obj(), the
> read-only test I added will be rejected. SInce the read will hit that
> code block and trigger the allocated object must have a referenced
> id".
> if (type_is_alloc(reg->type) &&
>     !type_is_non_owning_ref(reg->type) &&
>     !(reg->type & MEM_RCU) &&
>     !reg_is_referenced(env, reg)) {
> verifier_bug(env, "allocated object must have a referenced id");
> return -EFAULT;
> }

We can make a specific exception in this case IMO. That is easier to reason
about than allowing it by default everywhere. We can even add a comment about
it.

>
> There are 2 possible solutions:
> 1. Split the type_is_ptr_alloc_obj into 2 helpers, one is only
> checking whether the pointer has PTR_TO_BTF_ID | MEM_ALLOC, the other
> one checks if it is also trusted:
> static inline bool type_is_any_ptr_alloc_obj(u32 type)
> {
> return base_type(type) == PTR_TO_BTF_ID &&
>        type_flag(type) & MEM_ALLOC;
> }
> static inline bool type_is_ptr_alloc_obj(u32 type)
> {
> return type_is_any_ptr_alloc_obj(type) &&
>        !(type_flag(type) & PTR_UNTRUSTED);
> }

I would just create another more specific type_is_untrusted_ptr_alloc_obj().
Tighten existing type_is_ptr_alloc_obj() to exclude untrusted case.

Then just add "&& !type_is_untrusted_ptr_alloc_obj(...)" to the list of existing
checks before the error you pointed out above.

In addition, I would add a comment saying that the BPF_WRITE case for the
type_is_untrusted_ptr_alloc_obj() types was already rejected earlier, so this
check only permits reads on them.

Then the test you mentioned should continue passing.

> reg_btf_record() will use type_is_any_ptr_alloc_obj since it only
> looks up metadata, while bpf_refcount_acquire should use
> type_is_ptr_alloc_obj.

Is reg_btf_record() going to ever get such a pointer as input? From my cursory
look that doesn't seem so. It was happening before since such pointers could be
passed around to helpers or kfuncs. That should not be the case anymore.

>
> 3. Keep the untrusted pointer check on top like the current patch.


  reply	other threads:[~2026-08-03  7:21 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-26 23:50 [PATCH bpf v2 0/2] bpf: Fix refcount_acquire handling for borrowed kptrs Ning Ding
2026-07-26 23:50 ` [PATCH bpf v2 1/2] bpf: Keep refcount_acquire nullable for borrowed RCU kptrs Ning Ding
2026-07-27  4:50   ` Greg KH
2026-07-26 23:50 ` [PATCH bpf v2 2/2] bpf: Reject untrusted pointers in refcount_acquire Ning Ding
2026-07-27  0:13   ` sashiko-bot
2026-07-27  0:40     ` Ning Ding
2026-07-27  4:50   ` Greg KH
2026-08-02 23:29   ` Kumar Kartikeya Dwivedi
2026-08-03  5:57     ` Ning Ding
2026-08-03  6:08       ` Kumar Kartikeya Dwivedi
2026-08-03  6:48         ` Ning Ding
2026-08-03  6:50           ` Kumar Kartikeya Dwivedi
2026-08-03  7:10             ` Ning Ding
2026-08-03  7:21               ` Kumar Kartikeya Dwivedi [this message]
2026-08-03  7:44                 ` Ning Ding
2026-08-03  7:48                   ` 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=DKF4LVGKEKE2.2LUROK1TAUGZ0@gmail.com \
    --to=memxor@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=dingning04@gmail.com \
    --cc=eddyz87@gmail.com \
    --cc=greg@kroah.com \
    --cc=martin.lau@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 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.