linux-kernel - Re: [PATCH] perf: Fix data race in perf_event_set_bpf

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAEf4BzahX2oRRU7a9n8NsM-b+MMMjbDKpOEXe_zpR8XQ9=9H=A@mail.gmail.com>
Date: Fri, 30 Jan 2026 12:32:29 -0800
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Henry Zhang <henryzhangjcle@...il.com>, mingo@...hat.com, acme@...nel.org, 
	linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org, 
	syzkaller-bugs@...glegroups.com, Henry Zhang <zeri@...ch.edu>, 
	syzbot+2a077cb788749964cf68@...kaller.appspotmail.com, andrii@...nel.org
Subject: Re: [PATCH] perf: Fix data race in perf_event_set_bpf_handler()

On Fri, Jan 30, 2026 at 2:23 AM Peter Zijlstra <peterz@...radead.org> wrote:
>
> On Mon, Jan 26, 2026 at 09:36:18PM -0500, Henry Zhang wrote:
> > KCSAN reported a data race where perf_event_set_bpf_handler() writes
> > event->prog while __perf_event_overflow() reads it concurrently from
> > interrupt context:
> >
> > BUG: KCSAN: data-race in __perf_event_overflow / __perf_event_set_bpf_prog
> >
> > write to 0xffff88811b219168 of 8 bytes by task 13065 on cpu 0:
> >  perf_event_set_bpf_handler kernel/events/core.c:10352 [inline]
> >  __perf_event_set_bpf_prog+0x418/0x470 kernel/events/core.c:11303
> > ...
> >
> > read to 0xffff88811b219168 of 8 bytes by interrupt on cpu 1:
> >  __perf_event_overflow+0x252/0x920 kernel/events/core.c:10410
> > ...
> >
> > Annotate event->prog access with WRITE_ONCE/READ_ONCE.
> >
> > Reported-by: syzbot+2a077cb788749964cf68@...kaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=2a077cb788749964cf68
> > Signed-off-by: Henry Zhang <zeri@...ch.edu>
> > ---
> >  kernel/events/core.c | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/kernel/events/core.c b/kernel/events/core.c
> > index a0fa488bce84..1f3ed9e87507 100644
> > --- a/kernel/events/core.c
> > +++ b/kernel/events/core.c
> > @@ -10349,7 +10349,7 @@ static inline int perf_event_set_bpf_handler(struct perf_event *event,
> >               return -EPROTO;
> >       }
> >
> > -     event->prog = prog;
> > +     WRITE_ONCE(event->prog, prog);
> >       event->bpf_cookie = bpf_cookie;
>
> What about that cookie thing? The consumer seems to be a bpf function
> (bpf_get_attach_cookie_pe) which can equally run concurrently, no?
>
> Also, there seems to be a coherency issue here, if prog runs, it expects
> cookie to be present and all that.
>
> Would that not suggest something like:
>
>         WRITE_ONCE(event->bpf_cookie, bpf_cookie);
>         smp_store_release(&event->prog, prog);

yeah, once we set event->prog, we can theoretically have that BPF
program triggered before we set event->bpf_cookie.

But this setup thing is one-time and can be expensive...

>
> >       return 0;
> >  }
> > @@ -10407,7 +10407,9 @@ static int __perf_event_overflow(struct perf_event *event,
> >       if (event->attr.aux_pause)
> >               perf_event_aux_pause(event->aux_event, true);
> >
> > -     if (event->prog && event->prog->type == BPF_PROG_TYPE_PERF_EVENT &&
> > +     struct bpf_prog *prog = READ_ONCE(event->prog);
>
> smp_load_acquire(&event->prog);

while this is very frequent. So shouldn't we try to avoid unnecessary
overhead here? Maybe just use more expensive memory barriers in
perf_event_set_bpf_handler() to ensure that bpf_cookie will always be
set before event->prog can be seen by any CPU?

>
> > +
> > +     if (prog && prog->type == BPF_PROG_TYPE_PERF_EVENT &&
> >           !bpf_overflow_handler(event, data, regs))
> >               goto out;
> >
>
> Hmm?