On Tue, Jul 15, 2025 at 12:58 AM Shankari Anand <shankari.ak0208@xxxxxxxxx> wrote: > > syzbot reported a data race on the `ref` field of `struct bpf_lru_node`: > https://syzkaller.appspot.com/bug?extid=ad4661d6ca888ce7fe11 > > This race arises when user programs read the `.ref` field from a BPF map > that uses LRU logic, potentially exposing unprotected state. > > Accesses to `ref` are already wrapped with READ_ONCE() and WRITE_ONCE(). > However, the BPF verifier currently allows unprivileged programs to > read this field via BTF-enabled pointer, bypassing internal assumptions. > > To mitigate this, the verifier is updated to disallow access > to the `.ref` field in `struct bpf_lru_node`. > This is done by checking both the base type and field name > in `check_ptr_to_btf_access()` and returning -EACCES if matched. > > Reported-by: syzbot+ad4661d6ca888ce7fe11@xxxxxxxxxxxxxxxxxxxxxxxxx > Closes: https://lore.kernel.org/all/6847e661.a70a0220.27c366.005d.GAE@xxxxxxxxxx/T/ > Signed-off-by: Shankari Anand <shankari.ak0208@xxxxxxxxx> > --- > kernel/bpf/verifier.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c > index 169845710c7e..775ce454268c 100644 > --- a/kernel/bpf/verifier.c > +++ b/kernel/bpf/verifier.c > @@ -7159,6 +7159,19 @@ static int check_ptr_to_btf_access(struct bpf_verifier_env *env, > } > > ret = btf_struct_access(&env->log, reg, off, size, atype, &btf_id, &flag, &field_name); > + > + /* Block access to sensitive kernel-internal fields */ This makes no sense. Tracing bpf progs are allowed to read all kernel internal data fields. Also you misread the kcsan report. It says that 'read' comes from: read to 0xffff888118f3d568 of 4 bytes by task 4719 on cpu 1: lookup_nulls_elem_raw kernel/bpf/hashtab.c:643 [inline] which is reading hash and key of htab_elem while write side actually writes hash too: *(u32 *)((void *)node + lru->hash_offset) = hash; Martin, is it really possible for these read/write to race ? -- pw-bot: cr
