Re: [PATCH bpf 2/4] bpf: Require CAP_PERFMON for kfuncs reading memory

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Thu Sep 10, 2026 at 7:21 AM PDT, Daniel Borkmann wrote:
> Mark fault-safe probe reading kfuncs as KF_PERFMON, similarly as we do for
> the old-style BPF helper equivalents. bpf_rdonly_cast() is included in this
> list as well as it returns PTR_TO_MEM | MEM_RDONLY | PTR_UNTRUSTED for an
> unchecked object and is using fault-safe BPF_PROBE_MEM.
>
> Note that only the void form of bpf_rdonly_cast() produced a register that
> was readable without CAP_PERFMON. For a struct type id the kfunc returns
> PTR_TO_BTF_ID | PTR_UNTRUSTED, whose dereference has always been gated in
> check_ptr_to_btf_access(). The flag is not conditional on the type id, so
> for the latter it only moves the rejection from the dereference to the call
> itself, which is the better place to report it anyway.
>
> The bpf_stream_vprintk() and bpf_stream_print_stack() kfuncs are marked
> as well. The former ends up in the same bpf_bprintf_prepare() as the
> bpf_snprintf() helper, where %pks, %pus and %pI4 read through a program-
> supplied address and %pB resolves one into a symbol. The latter walks the
> stack and prints each instruction pointer via %pS.
>
> Fixes: 4665415975b0 ("bpf: Add bits iterator")
> Fixes: 65ab5ac4df01 ("bpf: Add bpf_copy_from_user_str kfunc")
> Fixes: f0f8a5b58f78 ("bpf: Add bpf_copy_from_user_task_str() kfunc")
> Fixes: a498ee7576de ("bpf: Implement dynptr copy kfuncs")
> Fixes: f2362a57aeff ("bpf: allow void* cast using bpf_rdonly_cast()")
> Fixes: e91370550f1f ("bpf: Add kfuncs for read-only string operations")
> Fixes: 5ab154f1463a ("bpf: Introduce BPF standard streams")
> Fixes: 19559e844184 ("bpf: add bpf_strcasecmp kfunc")
> Fixes: b5b693f73589 ("bpf: add bpf_strcasestr,bpf_strncasestr kfuncs")
> Fixes: 1dc669646762 ("bpf: add bpf_strncasecmp kfunc")
> Fixes: 63328bb23f26 ("bpf: Add bpf_stream_print_stack stack dumping kfunc")

Let's drop this Fixes list altogether, since it will only cause
headaches to stable folks. We don't need to backport this everywhere.
Not really an issue.
CAP_BPF alone can leak memory via HW speculation,
so this patch isn't strictly necessary, but I don't mind closing the hole
since AI keeps reporting it.

Also pls add bpf_get_kmem_cache() as AI suggested.