Re: [BUG] usb: gadgetfs: KASAN null-ptr-deref and intermittent UAF in ep_aio_cancel()

[Minseo Kim]

Hi Alan,

> Is it okay to add your Tested-by: tag?

Yes, please add:

Tested-by: Minseo Kim <neck3922@xxxxxxxxx>

Thank you for the time and care you have put into this fix. I have learned
a great deal while working through this issue with you.

Best regards,
Minseo Kim

2026년 9월 5일 (토) 오전 5:10, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>님이 작성:
>
> On Fri, Sep 04, 2026 at 11:00:23PM +0900, Minseo Kim wrote:
> > Hi Alan,
> >
> > Thank you for the updated patch.
> >
> > > If you trim your patch down to the parts that only target the AIO races,
> > > do you get anything significantly different from my version?
> >
> > I compared your current patch with my AIO-only version and found no
> > significant difference in the AIO cancellation state machine or IRQ-state
> > handling.
> >
> > Both versions snapshot epdata and ep alongside req before
> > usb_ep_dequeue(). In the directed cross-CPU test, a control based on your
> > current patch but without the local snapshots of epdata and ep reproduced
> > the earlier ep_unlink_worker() UAF; I did not reproduce it with your
> > current patch.
> >
> > The only substantive implementation difference I found in the AIO-only
> > comparison was the criterion used alongside the req->actual check to
> > decide whether to queue copy work. My version used
> > iov_iter_count(&priv->to), whereas your current patch uses the explicit
> > is_read flag. I agree that is_read makes this decision more explicit and
> > avoids requiring the reader to infer it from how priv->to is initialized.
> >
> > With your current patch, native PREAD and one- and two-segment PREADV
> > copied their payloads correctly. PWRITE, PWRITEV, and zero-length PREAD
> > and PWRITE completed without invoking ep_user_copy_worker().
> >
> > I also reran the original null-ptr-deref and UAF reproducers, the exact
> > pre-queue cancellation matrix, and the reproducers for the earlier
> > candidate-patch regressions. I separately tested deferred giveback,
> > forced dequeue failure, and the earlier NULL-endpoint case. All of these
> > tests produced the expected results, and none of the corresponding
> > earlier failure signatures recurred.
> >
> > One small point in the ep_aio_cancel() comment: as I understand it, the
> > completion function pointer in struct kiocb is named ki_complete, which
> > is also the name I used in my previous message. I wondered whether
> > iocb->kio_complete() was intended to be iocb->ki_complete().
>
> Yes, that was simply a typo.  Thanks for spotting it.
>
> > Thank you again for updating the patch.
>
> You're welcome.  And now it's time to submit this patch.  Is it okay
> to add your Tested-by: tag?
>
> Alan Stern