Re: [PATCH v2] irq_work: Fix use-after-free in irq_work_single on PREEMPT_RT

From: Xi Ruoyao

Date: Fri Jun 05 2026 - 06:41:01 EST


On Thu, 2026-04-02 at 08:50 +0200, Sebastian Andrzej Siewior wrote:
> On 2026-03-30 15:32:29 [+0800], Jiayuan Chen wrote:
> > On PREEMPT_RT, non-HARD irq_work runs in per-CPU kthreads via
> > run_irq_workd(), so irq_work_sync() uses rcuwait to wait for
> > BUSY==0.
> >
> > After irq_work_single() clears BUSY via atomic_cmpxchg(), it still
> > dereferences @work for irq_work_is_hard() and rcuwait_wake_up().
> > An irq_work_sync() caller on another CPU that enters after BUSY is
> > cleared can observe BUSY==0 immediately, return, and free the work
> > before those accesses complete — causing a use-after-free.
> >
> > Fix this by wrapping run_irq_workd() in guard(rcu)() so that the
> > entire irq_work_single() execution is within an RCU read-side
> > critical section. Then add synchronize_rcu() in irq_work_sync()
> > after rcuwait_wait_event() to ensure the caller waits for the RCU
> > grace period before returning, preventing premature frees.
> >
> > Fixes: 810979682ccc ("irq_work: Allow irq_work_sync() to sleep if irq_work() no IRQ support.")
> > Suggested-by: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx>
> > Suggested-by: Steven Rostedt <rostedt@xxxxxxxxxxx>
> > Signed-off-by: Jiayuan Chen <jiayuan.chen@xxxxxxxxx>
>
> Reviewed-by: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx>
>
> Sebastian

Hi,

This commit significantly slows down execve() (and perhaps other things)
on MIPS. A very simple program:

#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
int main(int argc, char **argv)
{
int x = argc > 1 ? atoi(argv[1]) : 114;
if (!x)
exit(0);

char buf[10];
sprintf(buf, "%d", x - 1);
execl("/proc/self/exe", argv[0], buf, NULL);
__builtin_trap();
}

now spends several (2 to 6) seconds on a Loongson 3A4000, with the
commit reverted it only spends 0.06 second.

I noticed https://lore.kernel.org/all/20260604182407.3109536-1-
jelonek.jonas@xxxxxxxxx/ but it doesn't help.

The kernel configuration is attached. Any thoughts?

--
Xi Ruoyao <xry111@xxxxxxxxxxx>

Attachment: config-mips.zst
Description: application/zstd