diff options
| author | Haocheng Yu <yuhaocheng035@gmail.com> | 2026-02-03 00:20:56 +0800 |
|---|---|---|
| committer | Peter Zijlstra <peterz@infradead.org> | 2026-02-23 11:19:25 +0100 |
| commit | 77de62ad3de3967818c3dbe656b7336ebee461d2 (patch) | |
| tree | 333170b2489214beb7f1f4f689b2bd34b1d2aa95 /kernel/rseq.c | |
| parent | 6a8a48644c4b804123e59dbfc5d6cd29a0194046 (diff) | |
perf/core: Fix refcount bug and potential UAF in perf_mmap
Syzkaller reported a refcount_t: addition on 0; use-after-free warning
in perf_mmap.
The issue is caused by a race condition between a failing mmap() setup
and a concurrent mmap() on a dependent event (e.g., using output
redirection).
In perf_mmap(), the ring_buffer (rb) is allocated and assigned to
event->rb with the mmap_mutex held. The mutex is then released to
perform map_range().
If map_range() fails, perf_mmap_close() is called to clean up.
However, since the mutex was dropped, another thread attaching to
this event (via inherited events or output redirection) can acquire
the mutex, observe the valid event->rb pointer, and attempt to
increment its reference count. If the cleanup path has already
dropped the reference count to zero, this results in a
use-after-free or refcount saturation warning.
Fix this by extending the scope of mmap_mutex to cover the
map_range() call. This ensures that the ring buffer initialization
and mapping (or cleanup on failure) happens atomically effectively,
preventing other threads from accessing a half-initialized or
dying ring buffer.
Closes: https://lore.kernel.org/oe-kbuild-all/202602020208.m7KIjdzW-lkp@intel.com/
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Haocheng Yu <yuhaocheng035@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/20260202162057.7237-1-yuhaocheng035@gmail.com
Diffstat (limited to 'kernel/rseq.c')
0 files changed, 0 insertions, 0 deletions
