From: sashiko-bot@kernel.org
To: "Fan Wu" <fanwu01@zju.edu.cn>
Cc: linux-hyperv@vger.kernel.org
Subject: Re: [PATCH net v2] net: mana: fix reset work race with device removal
Date: Sun, 06 Sep 2026 02:38:51 +0000 [thread overview]
Message-ID: <20260906023851.AC7981F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260905023602.425827-1-fanwu01@zju.edu.cn>
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.
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260905023602.425827-1-fanwu01@zju.edu.cn?part=1
next prev parent reply other threads:[~2026-09-06 2:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-05 2:36 [PATCH net v2] net: mana: fix reset work race with device removal Fan Wu
2026-09-06 2:38 ` sashiko-bot [this message]
2026-09-08 11:20 ` Simon Horman
2026-09-08 11:22 ` Simon Horman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260906023851.AC7981F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=fanwu01@zju.edu.cn \
--cc=linux-hyperv@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox