Re: [BUG] WARNING in perf_pending_task() outside do_exit() path
From: jihoon kim
Date: Mon Sep 07 2026 - 10:44:48 EST
Hi,
Apologies for missing the attachments in my previous email. I have attached the reproducer file (`repro_perf_pending_task.c`) for reference.
Apologies for missing the attachments in my previous email. I have attached the reproducer file (`repro_perf_pending_task.c`) for reference.
2026년 9월 7일 (월) 오후 11:33, jihoon kim <kigihi85@xxxxxxxxx>님이 작성:
Hi,
While fuzz testing mainline (syzkaller, arm64, local build) I hit the
following WARNING repeatedly and reliably:
------------[ cut here ]------------
WARNING: kernel/events/core.c:7629 at perf_pending_task+0x268/0x2a4, CPU#1: syz.1.79/2934
Modules linked in:
CPU: 1 UID: 0 PID: 2934 Comm: syz.1.79 Tainted: G W 7.2.0 #1 PREEMPT
Tainted: [W]=WARN
Hardware name: linux,dummy-virt (DT)
Call trace:
perf_pending_task+0x268/0x2a4 (P)
task_work_run+0x124/0x1ec
exit_to_user_mode_loop+0x1f4/0x210
el0_svc+0x1e0/0x270
el0t_64_sync_handler+0xa0/0xe4
el0t_64_sync+0x198/0x19c
---[ end trace 0000000000000000 ]---
This is the WARN_ON_ONCE in perf_sigtrap() (inlined into
perf_pending_task()):
static void perf_sigtrap(struct perf_event *event)
{
if (current->flags & PF_EXITING)
return;
if (WARN_ON_ONCE(event->ctx->task != current))
return;
...
}
Why I think this is worth a separate look
------------------------------------------
This exact function has a history of related issues:
- CVE-2022-48950: a use-after-free in perf_pending_task() (fixed by
extending the perf_event's refcount across the queued task_work,
commit 8bffa95ac19ff27c8261904f89d36c7fcf215d59). That fix
(put_event(event) at the end of perf_pending_task()) is present in
the tree I'm testing, so this is not that bug.
- commit 3da6bb419750 ("perf/core: Fix WARN in perf_sigtrap()"),
2025-09-04, fixed a WARN at this same line, but for a call path that
goes through do_exit()/do_group_exit()/get_signal() while the task is
actively exiting (ctx->task pinned to TASK_TOMBSTONE).
My reproduction's call trace has no do_exit()/get_signal() anywhere —
it's a completely ordinary syscall-return path (task_work_run ->
exit_to_user_mode_loop). So the task is not exiting, and the 2025-09-04
fix's precondition doesn't appear to apply here. I have not been able
to pin down exactly how event->ctx->task and current diverge outside
that exit path — reporting in case this rings a bell for people who
know this code better than I do.
Severity / impact
------------------
I don't believe this indicates memory corruption:
- The WARN_ON_ONCE only compares pointer values; nothing is
dereferenced before or after the check on the taken branch.
- This build has CONFIG_KASAN=y; no KASAN report accompanies the WARN.
- I also built a variant with CONFIG_KCSAN=y (KASAN and KCSAN can't be
enabled together in this tree) and reproduced the same WARN several
times; KCSAN did not report any data race.
So this looks like a WARN-only assertion violation (no observed
memory-safety impact), but given the recurring history of races in
this exact function, it seemed worth flagging rather than silently
working around it.
Reproducer
----------
Minimized by syzkaller to two syscalls:
perf_event_open(&(0x7f0000000000)={0x2, 0x80, 0x77, 0x0, 0x0, 0x0, 0x0, 0x9c29, 0x147cb, 0x8, 0x0, 0x1, 0x1, 0x0, 0x0, 0x0, 0x0, 0x1, 0x1, 0x1, 0x1, 0x1, 0x0, 0x0, 0x0, 0x2, 0x1, 0x0, 0x0, 0x1, 0x1, 0x1, 0x0, 0x0, 0x0, 0x1, 0x1, 0x1, 0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x1, 0x1, 0x1, 0x0, 0xb, 0x4, @perf_config_ext={0xfffffffffffffbff, 0x100}, 0xa1, 0x3, 0x4, 0x6, 0x7, 0x8, 0xfcbe, 0x0, 0x0, 0x0, 0x2}, 0x0, 0xffffffffffffffff, 0xffffffffffffffff, 0x2)
io_uring_setup(0x25fa, &(0x7f0000000180)={0x0, 0x6bc, 0x2, 0x0, 0xaa})
A standalone C reproducer (autogenerated by syzkaller) is attached
[repro_perf_pending_task.c]. It reproduces reliably within ~20-40s of
boot under syzkaller's syz-repro tool; I have not yet reduced it to a
hand-written minimal C repro independent of the syzkaller harness.
Kernel: mainline, local build tagged 7.2.0-g26260251022f-dirty
Arch: arm64, QEMU/KVM(hvf) virt machine, 2 vCPU / 2GB RAM
Happy to provide the full syzkaller log, the C repro, or test patches.
Thanks,
Jihoon Kim (Harumomonabi) <kigihi85@xxxxxxxxx>
Attachment:
repro_perf_pending_task.c
Description: Binary data