On Sun, Sep 06, 2026 at 02:38:51AM +0000, [email protected] wrote: > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) > to consider: > > Pre-existing issues: > - [High] Module text unmap race condition on worker thread exit due to unsafe > module_put(THIS_MODULE). > -- > > commit 690e7316a6c3698f99d06b66663e08bbcdb43123 > Author: Fan Wu <[email protected]> > > net: mana: fix reset work race with device removal > > This commit embeds the reset service work in the gdma_context and implements > admission gates using GC_REMOVING. This correctly synchronizes the service > work with device removal and probe unwinding to prevent use-after-free races > on the gdma_context. > > Cc: [email protected] > > > diff --git a/drivers/net/ethernet/microsoft/mana/gdma_main.c > > b/drivers/net/ethernet/microsoft/mana/gdma_main.c > > --- a/drivers/net/ethernet/microsoft/mana/gdma_main.c > > +++ b/drivers/net/ethernet/microsoft/mana/gdma_main.c > > @@ -796,48 +841,49 @@ static void mana_recovery_delayed_func(struct > > work_struct *w) > [ ... ] > > static void mana_serv_func(struct work_struct *w) > > { > [ ... ] > > + /* The rescan exits of mana_do_service() remove the device, which > > + * frees gc before returning. Only touch the pdev and the module > > + * reference from here on; both are held until this point drops them. > > + */ > > pci_dev_put(pdev); > > - kfree(mns_wk); > > module_put(THIS_MODULE); > > [Severity: High] > This isn't a bug introduced by this patch, but is it safe to call > module_put(THIS_MODULE) directly at the end of a work item executing > inside the module's text segment? > > If a user unloads the module concurrently with mana_serv_func() executing, > the module unload process (rmmod) will wait until the refcount reaches 0. > When this worker thread executes module_put(THIS_MODULE), the refcount > drops to 0. > > If the worker thread is preempted right after this call and before returning > to the workqueue core, the module unload can complete and free the module > text memory. > > When the worker thread resumes and attempts to return, it will fetch > instructions from unmapped memory, resulting in a use-after-free panic.
It seems to me that this pre-existing problem should not block progress of this patch.
