Re: [PATCH] memstick: core: reclaim the request before freeing a timed-out card

[Ulf Hansson]

On Tue, Sep 29, 2026 at 12:24 PM Ulf Hansson
<ulf.hansson@xxxxxxxxxxxxxxxx> wrote:
>
> On Sat, Sep 19, 2026 at 12:06 PM Nguyen Ngoc Thang
> <ngocthang2710.1999@xxxxxxxxx> wrote:
> >
> > memstick_alloc_card() hands card->current_mrq to the host and waits 500 ms
> > for it. If the host is still busy, the wait times out, the card is freed,
> > but the host keeps its pointer to the freed request.
> >
> > rtsx_usb_ms hits this easily: its handle_req work can block in USB
> > transfers for seconds. When it returns, it reads and writes the freed
> > request, including the retry path in memstick_next_req():
> >
> >   BUG: KASAN: slab-use-after-free in rtsx_usb_ms_handle_req+0x17ff/0x1a00
> >   Read of size 1 by task kworker/1:3
> >   Workqueue: events rtsx_usb_ms_handle_req
> >   Allocated by task 1656:
> >    memstick_alloc_card
> >    memstick_check
> >   Freed by task 1656:
> >    memstick_alloc_card
> >    memstick_check
> >
> > Add an optional host->cancel() hook that stops the host from using the
> > current request, and call it from a common wait helper on timeout, before
> > the request's owner can go away. rtsx_usb_ms implements it by draining its
> > work item. The helper also covers memstick_set_rw_addr() and both waits in
> > memstick_alloc_card().
> >
> > Reported-by: syzbot+3ee5da0319ca17ef1f4e@xxxxxxxxxxxxxxxxxxxxxxxxx
> > Closes: https://syzkaller.appspot.com/bug?extid=3ee5da0319ca17ef1f4e
> > Fixes: 99451dceeb5f ("memstick: Add realtek USB memstick host driver")
> > Signed-off-by: Nguyen Ngoc Thang <ngocthang2710.1999@xxxxxxxxx>
> > ---
> > Testing: no hardware. A raw-gadget emulation of an RTS5129 (0bda:0129) on
> > dummy_hcd delays every bulk-IN reply by 550 ms (above the core's 500 ms wait,
> > below the driver's 600 ms USB timeout). On a KASAN kernel the unpatched tree
> > reproduces the report (same offset and alloc/free stacks); the patched tree
> > takes the timeout+cancel path (~0.6 s) with no KASAN.
> >
> > I first considered a second unbounded wait_for_completion() instead of a hook,
> > but rtsx_usb_ms_request() skips scheduling once host->eject is set and
> > memstick_remove_host() flushes the workqueue, so that can deadlock.
> >
> > Known limit: cancel waits for the worker's remaining retries (a few seconds
> > with a device that never answers) while memstick_check() holds host->lock.
> > Other hosts leave ->cancel NULL, so their behaviour is unchanged.
> >
> >  drivers/memstick/core/memstick.c    | 22 ++++++++++++++++------
> >  drivers/memstick/host/rtsx_usb_ms.c |  8 ++++++++
> >  include/linux/memstick.h            |  2 ++
> >  3 files changed, 26 insertions(+), 6 deletions(-)
>
> May I suggest that you split this into separate patches. For the core
> and for the rtsx_usb driver. Other than that, this seems reasonable to
> me.
>
> In fact, we should probably have something similar for mmc, as
> currently it's the mmc host driver responsibility to manage this
> timeout itself.

Reviewing another patch [1] for the same issue, indicates the memstick
host drivers are already managing the timeout themselves. So, even if
your approach seems reasonable, I decided to go with the other
solution for now.

[...]

Kind regards
Uffe

[1]
https://lore.kernel.org/all/20260924204142.607-1-rajojha047@xxxxxxxxx/