Re: [syzbot] [trace?] KASAN: slab-use-after-free Read in ring_buffer_iter_advance

[Steven Rostedt <rostedt@goodmis.org>]

On Mon, 03 Aug 2026 17:52:33 -0700
syzbot <syzbot+e0cc44465d6bae735679@syzkaller.appspotmail.com> wrote:

> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+e0cc44465d6bae735679@syzkaller.appspotmail.com

This is a legitimate bug.

> 
> ==================================================================
> BUG: KASAN: slab-use-after-free in rb_page_size kernel/trace/ring_buffer.c:391 [inline]
> BUG: KASAN: slab-use-after-free in rb_advance_iter+0x40e/0x460 kernel/trace/ring_buffer.c:6024
> Read of size 8 at addr ffff88802d79b8b8 by task syz.4.389/6869
> 
> CPU: 0 UID: 0 PID: 6869 Comm: syz.4.389 Not tainted syzkaller #0 PREEMPT(full) 
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/16/2026
> Call Trace:
>  <TASK>

>  rb_page_size kernel/trace/ring_buffer.c:391 [inline]
>  rb_advance_iter+0x40e/0x460 kernel/trace/ring_buffer.c:6024
>  ring_buffer_iter_advance+0x69/0x90 kernel/trace/ring_buffer.c:6445

The iterator is updated under the raw cpu_buffer reader lock.

> 
> Freed by task 6871:
>  kasan_save_stack+0x30/0x50 mm/kasan/common.c:57
>  kasan_save_track+0x14/0x30 mm/kasan/common.c:78
>  kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584
>  poison_slab_object mm/kasan/common.c:253 [inline]
>  __kasan_slab_free+0x5f/0x80 mm/kasan/common.c:285
>  kasan_slab_free include/linux/kasan.h:235 [inline]
>  slab_free_hook mm/slub.c:2677 [inline]
>  slab_free mm/slub.c:6377 [inline]
>  kfree+0x22b/0x6c0 mm/slub.c:6692
>  free_buffer_page kernel/trace/ring_buffer.c:399 [inline]
>  ring_buffer_subbuf_order_set+0x116b/0x18a0 kernel/trace/ring_buffer.c:7439

The pages are removed from the visible reader list onto a temporary link
list under the raw cpu_buffer reader lock.

After the reader lock is released, the list is then freed. No reader should
have access to any of these items as they were only visible under the
reader_lock.

The bug is that the ring buffer iterator keeps state! It can still have a
pointer to a sub-buffer that has been freed. When another read happens, it
may have a stale pointer.

The fix is to add some state to the cpu_buffer for when it frees pages so
that the next read from the iterator will reset its state.

I'll have to address this when I get some time.

Thanks,

-- Steve