The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: John Hubbard <jhubbard@nvidia.com>
To: Yunhui Cui <cuiyunhui@bytedance.com>,
	akpm@linux-foundation.org, david@kernel.org, jgg@ziepe.ca,
	peterx@redhat.com, yang.lee@linux.alibaba.com,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org
Subject: Re: [PATCH] mm/gup_test: fix race with PIN_LONGTERM_TEST ioctls
Date: Thu, 11 Jun 2026 21:20:30 -0700	[thread overview]
Message-ID: <932e1fa0-dd9e-47d2-9133-d3b2f78dcd97@nvidia.com> (raw)
In-Reply-To: <20260608025043.88087-1-cuiyunhui@bytedance.com>

On 6/7/26 7:50 PM, Yunhui Cui wrote:
> The PIN_LONGTERM_TEST helpers keep their state in global variables that
> are protected by pin_longterm_test_mutex when accessed from ioctl().
> However, gup_test_release() calls pin_longterm_test_stop() without
> holding that mutex.
> 
> This can race with PIN_LONGTERM_TEST_STOP and let two callers operate on
> the same pages array concurrently, corrupting the test state and possibly
> freeing it twice:

Let's add here that there are *no* such callers in the kernel, today.

> 
>  CPU 0                              CPU 1
>  -----                              -----
>  ioctl(PIN_LONGTERM_TEST_STOP)
>    mutex_lock(&pin_longterm_test_mutex)
>    pin_longterm_test_stop()
>      if (pin_longterm_test_pages)
>        kvfree(pin_longterm_test_pages)
> 
>                                     close()
>                                       gup_test_release()
>                                         pin_longterm_test_stop()
>                                           if (pin_longterm_test_pages)
>                                             kvfree(pin_longterm_test_pages)
> 
>      pin_longterm_test_pages = NULL
>    mutex_unlock(&pin_longterm_test_mutex)
> 
> Protect the release path with the same mutex so that stop and release
> cannot run pin_longterm_test_stop() concurrently.
> 
> Fixes: c77369b437f9 ("mm/gup_test: start/stop/read functionality for PIN LONGTERM test")
> Cc: stable@vger.kernel.org

umm, no, to "Cc: stable". This is the sort of thing that gives AI
a bad name. Specifically:

* Nothing in tree can possibly hit this race condition.

* This fix is purely static code analysis hygiene: correcting
  a theoretical problem that does not actually provide any
  sort of vulnerability fix in the kernel.

So claiming that the fix must go to stable is AI just making
overly grandiose claims, which I'm getting used to seeing lately,
but it still irritates.

> Signed-off-by: Yunhui Cui <cuiyunhui@bytedance.com>
> ---
>  mm/gup_test.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/mm/gup_test.c b/mm/gup_test.c
> index 9dd48db897b95..d1c2b1014f0ef 100644
> --- a/mm/gup_test.c
> +++ b/mm/gup_test.c
> @@ -373,7 +373,9 @@ static long gup_test_ioctl(struct file *filep, unsigned int cmd,
>  
>  static int gup_test_release(struct inode *inode, struct file *file)
>  {
> +	mutex_lock(&pin_longterm_test_mutex);
>  	pin_longterm_test_stop();
> +	mutex_unlock(&pin_longterm_test_mutex);
>  
>  	return 0;
>  }

With "Cc: stable", removed, please feel free to add:

Reviewed-by: John Hubbard <jhubbard@nvidia.com>

thanks,
-- 
John Hubbard


  reply	other threads:[~2026-06-12  4:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-08  2:50 [PATCH] mm/gup_test: fix race with PIN_LONGTERM_TEST ioctls Yunhui Cui
2026-06-12  4:20 ` John Hubbard [this message]
2026-06-12  6:47   ` David Hildenbrand (Arm)
2026-06-12  7:36 ` David Hildenbrand (Arm)
2026-08-10 10:23   ` [External] " yunhui cui
2026-08-10 11:02     ` David Hildenbrand (Arm)

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=932e1fa0-dd9e-47d2-9133-d3b2f78dcd97@nvidia.com \
    --to=jhubbard@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=cuiyunhui@bytedance.com \
    --cc=david@kernel.org \
    --cc=jgg@ziepe.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=peterx@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=yang.lee@linux.alibaba.com \
    /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