Re: [BUG] KASAN: slab-use-after-free Read in irq_migrate_all_off_this_cpu

[Farhad Alemi]

Hi Radu,

Please find attached the reproducer and the log; thanks!

On Sun, Aug 30, 2026 at 11:48 AM Radu Rendec <radu@xxxxxxxxxx> wrote:
>
> On Sun, 2026-08-30 at 20:30 +0200, Thomas Gleixner wrote:
> > On Sat, Aug 29 2026 at 16:34, Radu Rendec wrote:
> > > On Thu, 2026-08-27 at 22:41 -0700, Farhad Alemi wrote:
> > > >   BUG: KASAN: slab-out-of-bounds in
> > > > irq_migrate_all_off_this_cpu+0xdf/0xc80 kernel/irq/cpuhotplug.c:181
> > >
> > > Thanks for reporting this. For everyone interested, please note that it
> > > had been also reported by syzbot a few days before:
> > > https://lore.kernel.org/all/6a8c23a0.dbb3a75c.7844.0001.GAE@xxxxxxxxxx/
> > > Currently there is no follow up to the syzbot report.
> >
> > The syzbot report is useless. It mumbles about memory allocated in the
> > networking stack which definitely can't end up in the interrupt
> > descriptor :)
>
> I know, and that's why I asked for the reproducer :)
>
> The stack trace of the UAF is valid though (and pretty much identical
> to the one in Farhad's report). I was just trying to point out that
> it's very likely the same bug.
>
> > > > Our reproducer.c is available upon request.
> >
> > See further down the thread :)
>
> Yes, I saw your and Mark's replies, and you're clearly many steps ahead :)
> In hindsight, I admit I was lazy and didn't bother to look further - partly
> because I thought it would be easier to investigate once I had the reproducer.
>
> If I could go back in time and start doing this kind of work 20 years
> ago (or even 10), I would. It certainly helps figure things out much
> faster when you've been doing this for a long time and also know how
> the code evolved over the years.
>
> --
> Best regards,
> Radu

Attachment: 164_console.log
Description: Binary data

Attachment: reproducer.c
Description: Binary data