Re: [PATCH bpf-next v2 3/6] bpf: Reject a store through a fault prone pointer
| Newsgroups | org.kernel.vger.bpf |
|---|---|
| Message-ID | <5b81c3f28a2ca32623bdc5e1e2ca55d797d37739033a0ef1338f1c93bd6911bc@mail.kernel.org> |
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 814096ed835d..cbbb0c82d22c 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -5788,7 +5788,7 @@ static int check_ptr_to_btf_access(struct bpf_verifier_env *env,
> return -EACCES;
> }
>
> - if (atype != BPF_READ && (type_flag(reg->type) & PTR_UNTRUSTED)) {
> + if (atype != BPF_READ && bpf_may_fault_on_deref(reg->type)) {
> verbose(env, "only read is supported\n");
> return -EACCES;
> }
Does this change also reject HID-BPF writes to struct hid_device fields?
The HID struct_ops hid_bpf_ops_btf_struct_access() whitelists writes to
hid_device::name, ::uniq, and ::phys via WRITE_RANGE entries in
drivers/hid/bpf/hid_bpf_struct_ops.c. A HID program receives a
'struct hid_bpf_ctx *' argument that is PTR_TO_BTF_ID | PTR_TRUSTED, but
walking hctx->hid produces a bare PTR_TO_BTF_ID because
struct hid_bpf_ctx appears in no BTF_TYPE_SAFE_TRUSTED list in
check_ptr_to_btf_access().
Before this commit, 'hctx->hid->name[i] = c' passed the PTR_UNTRUSTED
test and reached env->ops->btf_struct_access(), where
hid_bpf_ops_btf_struct_access() returned 0 for offsets in the whitelisted
ranges and the store succeeded. After this commit,
bpf_may_fault_on_deref(PTR_TO_BTF_ID) is true and the store is rejected
with 'only read is supported' before the btf_struct_access callback runs.
The three WRITE_RANGE(hid_device, ...) entries become unreachable. The
commit message notes the bpf_qdisc Qdisc::next_sched case but does not
mention HID-BPF. If the intent is to preserve HID-BPF write capability,
hid_bpf_ctx::hid would need a trusted annotation
(BTF_TYPE_SAFE_TRUSTED(struct hid_bpf_ctx) { struct hid_device *hid; })
so the walked register stays PTR_TRUSTED. Otherwise, should the removal
be documented?
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/31845722500