Re: [BUG] usb: gadgetfs: KASAN null-ptr-deref and intermittent UAF in ep_aio_cancel()
From: Alan Stern
Date: Mon Sep 14 2026 - 12:11:03 EST
On Mon, Sep 14, 2026 at 11:00:00PM +0900, Minseo Kim wrote:
> Hi Alan,
>
> Thank you for the revised patch.
>
> Following your explanation, I focused this round of testing on how the
> revised patch handles module lifetime.
>
> I applied your first patch followed by this revised second patch to
> upstream v7.2-rc1, commit
> dc59e4fea9d83f03bad6bddf3fa2e52491777482, using
> CONFIG_USB_GADGETFS=m for the runtime tests.
...
> I also held ep_aio_complete() immediately after iocb->ki_complete() on
> the PWRITE path that does not queue copy_work. In two runs, each starting
> from a fresh boot, after the reproducer consumed the AIO completion event
> and closed all GadgetFS descriptors, unmount remained pending, at least
> one concurrent delete_module() attempt failed with errno set to
> EWOULDBLOCK, and gadgetfs_cleanup() did not begin while the callback tail
> was held. After I released the gate, the callback returned, unmount
> completed, and module removal succeeded.
Hmmm. Do you know where the unmount operation was getting stuck? Was
it the usb_gadget_unregister_driver() call inside dev_release()? I just
want to be sure about this.
> In another cancellation test, both unlink_work and copy_work were
> outstanding on gadgetfs_wq when rmmod entered destroy_workqueue().
> Releasing unlink_work alone did not allow cleanup to return; it returned
> only after I released copy_work.
>
> Using the GadgetFS source with both patches applied and without the
> diagnostic gates or markers, I reran the original NULL pointer dereference
> and UAF reproducers and the relevant AIO cancellation, payload, teardown,
> CPU hotplug, rebind, module reload, and partial read stress tests. All
> completed with the expected results and without a KASAN report, Oops, or
> LOCKDEP warning.
>
> In these x86-64 QEMU and dummy_hcd tests, module cleanup did not begin while
> a callback still had work to publish, and destroy_workqueue() waited for the
> remaining GadgetFS AIO work once module cleanup began. I did not find a new
> failure attributable to the revised second patch in these tests.
That all sounds very good.
> Thank you for examining this issue with such care and for the time and
> effort you have devoted to it.
And the same to you.
Alan Stern