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

[Alan Stern]

On Thu, Aug 20, 2026 at 06:40:19PM +0900, Minseo Kim wrote:
> Hi Alan,
> 
> Thank you for the revised patch and for your kind words about the testing.
> I applied it as posted to upstream v7.2-rc1, commit
> dc59e4fea9d83f03bad6bddf3fa2e52491777482.
> 
> I did not reproduce the previously reported ep_unlink_worker() UAF with
> this revision in the same directed cross-CPU diagnostic. I also reran the
> original null-ptr-deref and UAF reproducers and the reproducers for the
> earlier candidate-patch regressions, and did not observe their
> corresponding KASAN signatures.

Excellent!

> > Nor any of the old lockdep violations, I trust.
> 
> In the matched runs, I did not observe any of the previously reported
> LOCKDEP violations or any new violation attributable to this revision.
> The only LOCKDEP warning I observed was a ctx_lock IRQ-state warning that
> was also reproduced in matched runs on the unpatched kernel.

What was the cause of this warning?  If it is sufficiently 
straightforward, maybe I can fix it as well.

> > What happens if the aio is cancelled exactly between ep_aio()'s calls
> > to kiocb_set_cancel_fn() and usb_ep_queue()?
> 
> I exercised this exact interval by pausing the submitting thread in a
> return probe for kiocb_set_cancel_fn(), before control resumed in ep_aio()
> and before usb_ep_queue() was called. I released the submit path either
> when the return probe for ep_aio_cancel() ran or, separately, when the
> return probe for __x64_sys_io_cancel() ran. Both release points produced
> the same results described below.
> 
> When I allowed the queue operation to succeed, io_cancel() returned
> -EINPROGRESS in both the PWRITE and PREAD cases. ep_aio() then replayed
> the cancellation after the queue succeeded, and exactly one completion
> event reported res=-ECONNRESET.
> 
> When I forced the queue operation to return -EINVAL, io_cancel() again
> returned -EINPROGRESS in both cases, and exactly one completion event
> reported res=-EINVAL.
> 
> I also tested a 64-byte PWRITE for which dummy_hcd completed the request
> inside its queue callback. io_cancel() returned -EINPROGRESS, and exactly
> one completion event reported res=64.

Good, that's exactly what the results should be.

> None of these tested orderings produced an additional completion event,
> a KASAN report, or an Oops. In these tested orderings, the AIO_SUBMITTING
> handling produced exactly one completion in each case: an early
> cancellation was replayed after a pending queue succeeded, a failed queue
> produced one completion with its error, and an immediate completion did
> not produce a second completion.
> 
> I hope this answers the remaining question.

Yes, it all sounds good.  This patch is just about ready for submission.

Alan Stern