From: Richard Patel <ripatel@wii.dev>
To: Thomas Gleixner <tglx@kernel.org>
Cc: linux-kernel@vger.kernel.org, Marc Zyngier <maz@kernel.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Ingo Molnar <mingo@kernel.org>, Andy Lutomirski <luto@kernel.org>,
Josh Poimboeuf <jpoimboe@kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Charles Keepax <ckeepax@opensource.cirrus.com>,
David Rubin <david@vortan.dev>,
PJ Waskiewicz <pwaskiewicz@jumptrading.com>
Subject: [PATCH 0/2] genirq: fix use-after-free on abnormal IRQ thread exit
Date: Fri, 9 Oct 2026 14:58:40 +0000 [thread overview]
Message-ID: <20261009145842.1616117-1-ripatel@wii.dev> (raw)
When a threaded IRQ handler oopses on x86, the IRQ thread jumps to a
function pointer read from freed stack memory. This turned a benign oops
(NULL dereference) into a wild jump on Panther Lake with FRED.
This series fixes two lifetime bugs in the abnormal exit path of IRQ
threads:
1) irq_thread() stores a 'struct callback_head' (for exit_task_work())
on its stack, but the oops handler runs rewind_stack_and_make_dead()
before exit_task_work() runs.
2) A concurrent free_irq() and threaded IRQ oops can result in
free_irq() calling kfree(struct irqaction) before irq_thread_dtor()
runs in exit_task_work().
Whether this stack use-after-free causes a loud crash (wild jump) or
not probably depends on kernel config and FRED, since callback_head
might not get clobbered always.
I have some evidence of these use-after-free in the wild going back to
Linux 4.20, these are all variations of double faults in an IRQ thread's
exit_task_work().
* 2026-09 (confirmed)
* my Panther Lake laptop on recent x86 tip :-)
* 7.3.0+: Second fault in task_work_run, wild jump, IBT violation
* 2026-06 (confirmed)
* https://github.com/CachyOS/linux-cachyos/issues/882
* https://lore.kernel.org/r/CAFb0CM1X8_rxdfJGM-1D6i0=KDtv9tbMbuWi+PKAhTSMT+5NnA@mail.gmail.com
* 7.1.0-2-cachyos: Second fault in task_work_run, wild jump, IBT violation
* 7.1.0-1-mainline: Second fault in task_work_run, wild jump, NX violation
* 2024-07 (confirmed)
* https://bbs.archlinux.org/viewtopic.php?id=297634
* 6.9.9-arch: Second fault in task_work_run, wild jump to middle of
exit_shm, #PF
* 2024-05 (almost certain)
* https://lore.kernel.org/r/cover.1714762038.git.namcao@linutronix.de
* 6.8.6 (QEMU): Second fault in task_work_run, wild jump to NULL pointer
* 2023-01 (unsure)
* https://bugzilla.kernel.org/show_bug.cgi?id=216865
* 6.2-rc1 (Fedora): Second fault in irq_thread_dtor, GPF
* 2020-10 (likely)
* https://lore.kernel.org/r/a45db8d2-6902-7ec7-cab2-1436209a15a6@gmail.com
* 5.9.0: Second fault in task_work_run, wild jump to NULL pointer
* 2019-02 (unsure)
* https://lore.kernel.org/r/524648a9-3fb9-1423-aa1a-376289fafc5d@gmail.com
* 4.20.11 (Arch): Second fault in irq_thread_dtor, function call to NULL
And a few more which look sus but I'm too lazy to hand triage:
* https://github.com/CachyOS/linux-cachyos/issues/1027
* "the fault recovery itself triggers a second, more severe oops
(attempted execution of a non-executable page)"
* https://github.com/t2linux/T2-Debian-and-Ubuntu-Kernel/issues/215
* double oops / page fault on IRQ thread exit
* https://github.com/Dasharo/dasharo-issues/issues/1849
* wild jump on IRQ thread exit
* https://github.com/thesofproject/linux/issues/2676
* double oops, task_work_run+0x6e jump to NULL
* https://github.com/thesofproject/linux/issues/820
https://github.com/thesofproject/linux/issues/767
* double oops, task_work_run jump to NULL
* https://github.com/libthinkpad/dockd/issues/3
* double oops, task_work_run jump to heap address
* https://github.com/AMDESE/AMDSEV/issues/109
* double oops, task_work_run jump to middle of do_exit, crash in a
random mutex
* https://github.com/Askannz/optimus-manager/issues/176
* double oops, task_work_run jump to middle of do_exit
Richard Patel (2):
genirq: defer kfree(irqaction) until irq_thread_dtor() finishes
genirq: move IRQ thread exit_work object to irqaction
include/linux/interrupt.h | 2 ++
kernel/irq/internals.h | 2 ++
kernel/irq/manage.c | 30 +++++++++++++++++++++---------
3 files changed, 25 insertions(+), 9 deletions(-)
--
2.52.0
next reply other threads:[~2026-10-09 15:04 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-09 14:58 Richard Patel [this message]
2026-10-09 14:58 ` [PATCH 1/2] genirq: defer kfree(irqaction) until irq_thread_dtor() finishes Richard Patel
2026-10-09 14:58 ` [PATCH 2/2] genirq: move IRQ thread exit_work object to irqaction Richard Patel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261009145842.1616117-1-ripatel@wii.dev \
--to=ripatel@wii.dev \
--cc=bigeasy@linutronix.de \
--cc=ckeepax@opensource.cirrus.com \
--cc=david@vortan.dev \
--cc=jpoimboe@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=maz@kernel.org \
--cc=mingo@kernel.org \
--cc=pwaskiewicz@jumptrading.com \
--cc=tglx@kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®