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

[Alan Stern]

On Mon, Jul 20, 2026 at 10:18:33PM -0400, Alan Stern wrote:
> I've got some ideas on how to fix these problems, but we should discuss 
> a few things first.

Minseo, any responses to these questions?

> The real problem is that I don't have a clear idea of how the kernel's 
> aio implementation is meant to work, and it isn't documented at all.  So 
> there are a lot of questions about how the cancel function is supposed 
> to interact with the normal I/O pathways.
> 
> For instance, what is the cancel function supposed to do if it is called 
> before the submission function (ep_aio() in this case) has returned, and 
> the submission function eventually returns something other than 
> -EIOCBQUEUED (i.e., submission failed and no I/O was started)?  Or if it 
> is called before the submission function has started the actual I/O 
> operation, so there isn't anything to cancel yet?

Never mind this question; I can avoid the issue by not calling 
kiocb_set_cancel_fn() until after the request has been sucessfully 
submitted.

> What is the cancel function supposed to do if it is called after the I/O 
> has completed?  Should it return an error code?
> 
> What is supposed to happen if the I/O is cancelled and then completes 
> with no errors?

Presumably nothing special should happen in this case.  It should look 
more or less the same as in the previous question.

> How does the system handle a partial transfer, where the I/O was 
> cancelled part way through?  How does the user learn how much data was 
> transferred before the I/O was cancelled?

Presumably the second argument to ki_complete() contains this 
information.

This leaves only one question for you to answer.  :-)

Alan Stern