All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Naveen Kumar Chaudhary" <naveen.osdev@gmail.com>
Cc: linux-modules@vger.kernel.org
Subject: Re: [PATCH] module: dups: don't hold mutex across synchronize_rcu()
Date: Tue, 02 Jun 2026 04:24:40 +0000	[thread overview]
Message-ID: <20260602042440.996331F00893@smtp.kernel.org> (raw)
In-Reply-To: <ajydyxgaea27rhcopp5eauji24znotu65d2b4uw344yvmwcc6f@7l5re6f2xcuk>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Use-After-Free due to missing reference counting on kmod_req.
--

commit 6715d39010e803da11ebd165eb2b1fa9278aa3d7
Author: Naveen Kumar Chaudhary <naveen.osdev@gmail.com>

module: dups: don't hold mutex across synchronize_rcu()

This commit optimizes kmod_dup_request_delete() by moving synchronize_rcu()
outside the kmod_dup_mutex critical section. This prevents blocking other
mutex users during the RCU grace period.

> diff --git a/kernel/module/dups.c b/kernel/module/dups.c
> index 1d720a5311ba0..46e74c06ed52d 100644
> --- a/kernel/module/dups.c
> +++ b/kernel/module/dups.c
> @@ -88,8 +88,8 @@ static void kmod_dup_request_delete(struct work_struct *work)
>  	 */
>  	mutex_lock(&kmod_dup_mutex);
>  	list_del_rcu(&kmod_req->list);
> -	synchronize_rcu();
>  	mutex_unlock(&kmod_dup_mutex);
> +	synchronize_rcu();
>  	kfree(kmod_req);

[Severity: High]
This is a pre-existing issue, but does this code leave kmod_req vulnerable
to a use-after-free since waiters don't hold a reference count?

In kmod_dup_request_exists_wait(), a duplicate requester drops kmod_dup_mutex
and blocks on wait_for_completion_state(&kmod_req->first_req_done). If the
original thread finishes loading and calls kmod_dup_request_complete(), it
queues this delete_work with an arbitrary 60-second delay.

If the waiter is preempted or otherwise delayed for more than 60 seconds
(either before blocking, or after waking up but before reading
kmod_req->dup_ret), kmod_dup_request_delete() will free kmod_req here.

The synchronize_rcu() call does not protect the waiter because the waiter
sleeps in wait_for_completion_state() and cannot hold an RCU read lock.
When the waiter resumes, it could attempt lock operations on the freed
completion structure's waitqueue lock, or read kmod_req->dup_ret, resulting
in a use-after-free.

Would it be safer to add explicit reference counting to kmod_req to ensure
it remains allocated until all waiters have resumed and finished reading?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/ajydyxgaea27rhcopp5eauji24znotu65d2b4uw344yvmwcc6f@7l5re6f2xcuk?part=1

  reply	other threads:[~2026-06-02  4:24 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-02  4:17 [PATCH] module: dups: don't hold mutex across synchronize_rcu() Naveen Kumar Chaudhary
2026-06-02  4:24 ` sashiko-bot [this message]
2026-06-02  7:50 ` Petr Pavlu

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=20260602042440.996331F00893@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=naveen.osdev@gmail.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.