kernel/events/core.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
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@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=2a077cb788749964cf68
Signed-off-by: Henry Zhang <zeri@umich.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;
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);
+
+ if (prog && prog->type == BPF_PROG_TYPE_PERF_EVENT &&
!bpf_overflow_handler(event, data, regs))
goto out;
--
2.34.1On 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@syzkaller.appspotmail.com > Closes: https://syzkaller.appspot.com/bug?extid=2a077cb788749964cf68 > Signed-off-by: Henry Zhang <zeri@umich.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); > 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); > + > + if (prog && prog->type == BPF_PROG_TYPE_PERF_EVENT && > !bpf_overflow_handler(event, data, regs)) > goto out; > Hmm?
On Fri, Jan 30, 2026 at 2:23 AM Peter Zijlstra <peterz@infradead.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@syzkaller.appspotmail.com > > Closes: https://syzkaller.appspot.com/bug?extid=2a077cb788749964cf68 > > Signed-off-by: Henry Zhang <zeri@umich.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?
On Fri, Jan 30, 2026 at 5:23 AM Peter Zijlstra <peterz@infradead.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@syzkaller.appspotmail.com > > Closes: https://syzkaller.appspot.com/bug?extid=2a077cb788749964cf68 > > Signed-off-by: Henry Zhang <zeri@umich.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); > > > 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); > > > + > > + if (prog && prog->type == BPF_PROG_TYPE_PERF_EVENT && > > !bpf_overflow_handler(event, data, regs)) > > goto out; > > > > Hmm? Thanks for the feedback. I'll send a v2 later in the day. -- Henry
On Tue, 27 Jan 2026 at 16:37, Qing Wang <wangqing7171@gmail.com> wrote:
> On Tue, 27 Jan 2026 at 10:36, Henry Zhang <henryzhangjcle@gmail.com> wrote:
> > 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;
> > 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);
> > +
> > + if (prog && prog->type == BPF_PROG_TYPE_PERF_EVENT &&
> > !bpf_overflow_handler(event, data, regs))
> > goto out;
>
> Looking at this code, I guess there may be an serious issue: a potential
> use-after-free (UAF) risk when accessing event->prog in __perf_event_overflow.
>
> CPU 0 (interrupt context) CPU 1 (process context)
> read event->prog
> perf_event_free_bpf_handler()
> put(prog)
> free(prog)
> access memory pointed to by prog
>
> This scenario need to be more analysis.
>
> --
> Qing
This is my idea for solving the problem of data competition and potential UAF.
diff --git a/kernel/events/core.c b/kernel/events/core.c
index a0fa488bce84..3abf3689157d 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -10291,7 +10291,12 @@ static inline bool sample_is_allowed(struct perf_event *event, struct pt_regs *r
}
#ifdef CONFIG_BPF_SYSCALL
+/*
+ * Execute the attached BPF program. Caller must ensure prog is non-NULL
+ * and of type BPF_PROG_TYPE_PERF_EVENT under RCU protection.
+ */
static int bpf_overflow_handler(struct perf_event *event,
+ struct bpf_prog *prog,
struct perf_sample_data *data,
struct pt_regs *regs)
{
@@ -10299,22 +10304,17 @@ static int bpf_overflow_handler(struct perf_event *event,
.data = data,
.event = event,
};
- struct bpf_prog *prog;
int ret = 0;
ctx.regs = perf_arch_bpf_user_pt_regs(regs);
if (unlikely(__this_cpu_inc_return(bpf_prog_active) != 1))
goto out;
- rcu_read_lock();
- prog = READ_ONCE(event->prog);
- if (prog) {
- perf_prepare_sample(data, event, regs);
- ret = bpf_prog_run(prog, &ctx);
- }
- rcu_read_unlock();
+
+ perf_prepare_sample(data, event, regs);
+ ret = bpf_prog_run(prog, &ctx);
+
out:
__this_cpu_dec(bpf_prog_active);
-
return ret;
}
@@ -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;
return 0;
}
@@ -10361,13 +10361,14 @@ static inline void perf_event_free_bpf_handler(struct perf_event *event)
if (!prog)
return;
- event->prog = NULL;
+ WRITE_ONCE(event->prog, NULL);
bpf_prog_put(prog);
}
#else
static inline int bpf_overflow_handler(struct perf_event *event,
- struct perf_sample_data *data,
- struct pt_regs *regs)
+ struct bpf_prog *prog,
+ struct perf_sample_data *data,
+ struct pt_regs *regs)
{
return 1;
}
@@ -10407,9 +10408,19 @@ 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 &&
- !bpf_overflow_handler(event, data, regs))
+ /*
+ * For BPF-based overflow handling. If a BPF_PROG_TYPE_PERF_EVENT
+ * program is attached, execute it and skip default overflow handling.
+ */
+ rcu_read_lock();
+ struct bpf_prog *prog = rcu_dereference(event->prog);
+
+ if (prog && prog->type == BPF_PROG_TYPE_PERF_EVENT &&
+ !bpf_overflow_handler(event, prog, data, regs)) {
+ rcu_read_unlock();
goto out;
+ }
+ rcu_read_unlock();
/*
* XXX event_limit might not quite work as expected on inherited
What do you think about this solution? Looking forward to your review.
--
Qing
Thanks, this looks good.
--
Henry
On Tue, Jan 27, 2026 at 5:36 AM Qing Wang <wangqing7171@gmail.com> wrote:
>
> On Tue, 27 Jan 2026 at 16:37, Qing Wang <wangqing7171@gmail.com> wrote:
> > On Tue, 27 Jan 2026 at 10:36, Henry Zhang <henryzhangjcle@gmail.com> wrote:
> > > 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;
> > > 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);
> > > +
> > > + if (prog && prog->type == BPF_PROG_TYPE_PERF_EVENT &&
> > > !bpf_overflow_handler(event, data, regs))
> > > goto out;
> >
> > Looking at this code, I guess there may be an serious issue: a potential
> > use-after-free (UAF) risk when accessing event->prog in __perf_event_overflow.
> >
> > CPU 0 (interrupt context) CPU 1 (process context)
> > read event->prog
> > perf_event_free_bpf_handler()
> > put(prog)
> > free(prog)
> > access memory pointed to by prog
> >
> > This scenario need to be more analysis.
> >
> > --
> > Qing
>
> This is my idea for solving the problem of data competition and potential UAF.
>
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index a0fa488bce84..3abf3689157d 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -10291,7 +10291,12 @@ static inline bool sample_is_allowed(struct perf_event *event, struct pt_regs *r
> }
>
> #ifdef CONFIG_BPF_SYSCALL
> +/*
> + * Execute the attached BPF program. Caller must ensure prog is non-NULL
> + * and of type BPF_PROG_TYPE_PERF_EVENT under RCU protection.
> + */
> static int bpf_overflow_handler(struct perf_event *event,
> + struct bpf_prog *prog,
> struct perf_sample_data *data,
> struct pt_regs *regs)
> {
> @@ -10299,22 +10304,17 @@ static int bpf_overflow_handler(struct perf_event *event,
> .data = data,
> .event = event,
> };
> - struct bpf_prog *prog;
> int ret = 0;
>
> ctx.regs = perf_arch_bpf_user_pt_regs(regs);
> if (unlikely(__this_cpu_inc_return(bpf_prog_active) != 1))
> goto out;
> - rcu_read_lock();
> - prog = READ_ONCE(event->prog);
> - if (prog) {
> - perf_prepare_sample(data, event, regs);
> - ret = bpf_prog_run(prog, &ctx);
> - }
> - rcu_read_unlock();
> +
> + perf_prepare_sample(data, event, regs);
> + ret = bpf_prog_run(prog, &ctx);
> +
> out:
> __this_cpu_dec(bpf_prog_active);
> -
> return ret;
> }
>
> @@ -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;
> return 0;
> }
> @@ -10361,13 +10361,14 @@ static inline void perf_event_free_bpf_handler(struct perf_event *event)
> if (!prog)
> return;
>
> - event->prog = NULL;
> + WRITE_ONCE(event->prog, NULL);
> bpf_prog_put(prog);
> }
> #else
> static inline int bpf_overflow_handler(struct perf_event *event,
> - struct perf_sample_data *data,
> - struct pt_regs *regs)
> + struct bpf_prog *prog,
> + struct perf_sample_data *data,
> + struct pt_regs *regs)
> {
> return 1;
> }
> @@ -10407,9 +10408,19 @@ 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 &&
> - !bpf_overflow_handler(event, data, regs))
> + /*
> + * For BPF-based overflow handling. If a BPF_PROG_TYPE_PERF_EVENT
> + * program is attached, execute it and skip default overflow handling.
> + */
> + rcu_read_lock();
> + struct bpf_prog *prog = rcu_dereference(event->prog);
> +
> + if (prog && prog->type == BPF_PROG_TYPE_PERF_EVENT &&
> + !bpf_overflow_handler(event, prog, data, regs)) {
> + rcu_read_unlock();
> goto out;
> + }
> + rcu_read_unlock();
>
> /*
> * XXX event_limit might not quite work as expected on inherited
>
> What do you think about this solution? Looking forward to your review.
> --
> Qing
On Wed, 28 Jan 2026 at 05:29, Henry Zhang <zeri@umich.edu> wrote: > Thanks, this looks good. I thought my patch is incorrect after review. 1. The RCU protects 'prog->aux' but not 'prog', so 'rcu_dereference(event->prog)' is incorrect. 2. The UAF issue of 'prog' may not exist. It's needed further anlysis. Let's forget my patch. The data race is correctly fixed by your patch but there is still a little suggestion: The 'event->prog = NULL' in perf_event_free_bpf_handler is needed WRITE_ONCE. -- Best regards, Qing
On Wed, 28 Jan 2026 at 05:29, Henry Zhang <zeri@umich.edu> wrote: > Thanks, this looks good. Thanks for your review. Let's wait for maintainer's reply. -- Qing
On Tue, 27 Jan 2026 at 10:36, Henry Zhang <henryzhangjcle@gmail.com> wrote:
> 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;
> 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);
> +
> + if (prog && prog->type == BPF_PROG_TYPE_PERF_EVENT &&
> !bpf_overflow_handler(event, data, regs))
> goto out;
Looking at this code, I guess there may be an serious issue: a potential
use-after-free (UAF) risk when accessing event->prog in __perf_event_overflow.
CPU 0 (interrupt context) CPU 1 (process context)
read event->prog
perf_event_free_bpf_handler()
put(prog)
free(prog)
access memory pointed to by prog
This scenario need to be more analysis.
--
Qing
On Tue, Jan 27, 2026 at 04:37:19PM +0800, Qing Wang wrote: > On Tue, 27 Jan 2026 at 10:36, Henry Zhang <henryzhangjcle@gmail.com> wrote: > > 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; > > 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); > > + > > + if (prog && prog->type == BPF_PROG_TYPE_PERF_EVENT && > > !bpf_overflow_handler(event, data, regs)) > > goto out; > > Looking at this code, I guess there may be an serious issue: a potential > use-after-free (UAF) risk when accessing event->prog in __perf_event_overflow. > > CPU 0 (interrupt context) CPU 1 (process context) > read event->prog > perf_event_free_bpf_handler() > put(prog) > free(prog) > access memory pointed to by prog > > This scenario need to be more analysis. This can only happen if the event can overlap with removal, which it typically cannot -- but I'll have to audit the software events. Specifically, events happen in IRQ/NMI context, and event removal involves an IPI to that very CPU, which by necessity will then have to wait for event completion.
© 2016 - 2026 Red Hat, Inc.