Re: [PATCH net v2] net: mana: fix reset work race with device removal

[Simon Horman <horms@kernel.org>]

On Sun, Sep 06, 2026 at 02:38:51AM +0000, sashiko-bot@kernel.org 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 <fanwu01@zju.edu.cn>
> 
> 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: stable@vger.kernel.org
> 
> > 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.