Re: [syzbot] [trace?] KASAN: use-after-free Write in ring_buffer_read_page

[Aleksandr Nogikh]

On Wed, Jun 3, 2026 at 3:34 AM 'Masami Hiramatsu' via syzkaller-bugs
<syzkaller-bugs@xxxxxxxxxxxxxxxx> wrote:
>
> On Tue, 2 Jun 2026 12:28:29 -0400
> Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>
> > On Tue, 02 Jun 2026 06:45:31 -0700
> > syzbot <syzbot+2dd9d02f60775ce5c1fb@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit:    e7ae89a0c97c Linux 7.1-rc5
> > > git tree:       upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=16f06e2e580000
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=58acee1ac5406016
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=2dd9d02f60775ce5c1fb
> > > compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
> > >
> > > Unfortunately, I don't have any reproducer for this issue yet.
> >
> > Looks like the test was doing something really weird to trigger this.
> > Without a reproducer, it's pretty much impossible to find out what
> > happened. Maybe AI could do it?
> >
>
> Does the "I don't have any reproducer for this issue yet." means
> this is not reproducible even if it runs completely same sequence
> in the console output? If so, might this be a timing related issue?
> (e.g. read v.s. write-event)

Yes, syzbot normally re-plays the sequence of last programs executed
on the crashed VM to find a reproducer, and, in many cases, they no
longer crash the kernel..

In the meanwhile, syzbot's AI bug reproduction functionality has found
a C reproducer for a KASAN crash in the kernel/trace's ring buffer,
although with a slightly different stack trace:
https://syzkaller.appspot.com/ai_job?id=b2620161-1632-4d4e-9314-114a8a5e79ef

Cc Alexander Potapenko

>
> Thanks,
>
> --
> Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>
>