From: Chengyu Liu <lui2012qwq@gmail.com>
To: linux-usb@vger.kernel.org
Cc: b-liu@ti.com, gregkh@linuxfoundation.org, nkapron@google.com,
tony@atomide.com, bigeasy@linutronix.de, balbi@ti.com,
shimoda.yoshihiro@renesas.com, robert.jarzmik@free.fr,
Chengyu Liu <lui2012qwq@gmail.com>
Subject: [PATCH 0/4] usb: stop timers/works left armed on teardown
Date: Fri, 13 Nov 2026 00:04:44 +0800 [thread overview]
Message-ID: <20261112160448.41566-1-lui2012qwq@gmail.com> (raw)
The teardown paths in these four drivers do not quiesce every producer
of asynchronous work before draining it: an interrupt handler may still
queue or re-arm a timer or work item after the cancellation, while the
corresponding object is being torn down. In three of them the IRQ is
devm-managed and freed only at detach, after remove() returns; in musb
the plain free_irq() happens later in the same remove path. Either way
a late interrupt re-arms the callback, which then runs on freed memory:
[1/4] musb core: musb_stage0_irq() can schedule irq_work while
handling stage-0 USB interrupts, and the work can also re-arm
itself from the session recheck path; musb_remove() cancels it
before masking the interrupts and before free_irq().
[2/4] musb dsps glue: the devm VBUS interrupt outlives the child
teardown that deletes musb->dev_timer; its handler re-arms
the timer via dsps_mod_timer().
[3/4] r8a66597: r8a66597_remove() deletes the timer while the devm
IRQ can still re-arm it from the VBINT path.
[4/4] gpio-vbus: gpio_vbus_remove() cancels the work while the devm
GPIO interrupt can still re-arm it (100 ms debounce delay).
Two further instances of this defect class found in the same sweep -
pch_udc and lpc32xx_udc - are being handled in Hyunjung Ko's
"usb: gadget: pch_udc: drain vbus GPIO works before freeing the
device" and "usb: gadget: lpc32xx_udc: drain the pullup work on
removal" threads, so they are not part of this series.
Testing:
[1-3/4] build-tested on x86_64 (COMPILE_TEST where needed); they
require hardware we do not have, so no runtime reproducer.
[4/4] additionally confirmed with a KASAN reproducer: the driver
probed on a gpio-sim chip in QEMU, slab-use-after-free write
in __run_timer_base() after unregister (5/5 runs), clean with
the fix (0/5). The KASAN report and the reproducer kit follow
in this thread.
All found by static analysis. Fixes written with AI assistance.
Chengyu Liu (4):
usb: musb: cancel irq_work after masking interrupts in musb_remove()
usb: musb: dsps: free the VBUS interrupt before the child teardown
usb: gadget: r8a66597: free the IRQ before deleting the timer
usb: phy: gpio-vbus: free the interrupt before cancelling the work
drivers/usb/gadget/udc/r8a66597-udc.c | 8 ++++++++
drivers/usb/gadget/udc/r8a66597-udc.h | 1 +
drivers/usb/musb/musb_core.c | 10 +++++++++-
drivers/usb/musb/musb_dsps.c | 11 +++++++++++
drivers/usb/phy/phy-gpio-vbus-usb.c | 8 ++++++++
5 files changed, 37 insertions(+), 1 deletion(-)
Signed-off-by: Chengyu Liu <lui2012qwq@gmail.com>
--
2.25.1
next reply other threads:[~2026-11-12 16:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-12 16:04 Chengyu Liu [this message]
2026-11-12 16:04 ` [PATCH 1/4] usb: musb: cancel irq_work after masking interrupts in musb_remove() Chengyu Liu
2026-11-12 16:04 ` [PATCH 2/4] usb: musb: dsps: free the VBUS interrupt before the child teardown Chengyu Liu
2026-11-12 16:04 ` [PATCH 3/4] usb: gadget: r8a66597: free the IRQ before deleting the timer Chengyu Liu
2026-11-12 16:18 ` sashiko-bot
2026-11-12 16:04 ` [PATCH 4/4] usb: phy: gpio-vbus: free the interrupt before cancelling the work Chengyu Liu
2026-11-12 16:16 ` sashiko-bot
2026-11-12 16:10 ` [PATCH 0/4] usb: stop timers/works left armed on teardown Chengyu Liu
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=20261112160448.41566-1-lui2012qwq@gmail.com \
--to=lui2012qwq@gmail.com \
--cc=b-liu@ti.com \
--cc=balbi@ti.com \
--cc=bigeasy@linutronix.de \
--cc=gregkh@linuxfoundation.org \
--cc=linux-usb@vger.kernel.org \
--cc=nkapron@google.com \
--cc=robert.jarzmik@free.fr \
--cc=shimoda.yoshihiro@renesas.com \
--cc=tony@atomide.com \
/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