All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pranjal Shrivastava <praan@google.com>
To: sashiko-reviews@lists.linux.dev
Cc: Chuck Lever <cel@kernel.org>, Anna Schumaker <anna@kernel.org>,
	Jeff Layton <jlayton@kernel.org>,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH v6 2/5] nfs: track number of pinned pages in nfs_page
Date: Fri, 14 Aug 2026 15:14:29 +0000	[thread overview]
Message-ID: <an8w1Zp7YkvkY7S-@google.com> (raw)
In-Reply-To: <20260814144713.DF1A21F000E9@smtp.kernel.org>

On Fri, Aug 14, 2026 at 02:47:13PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] Latent stack out-of-bounds read by passing a single local stack variable to unpin_user_pages() with a dynamically loaded length.
> --
> 
> --- Patch [2]: [PATCH v6 2/5] nfs: track number of pinned pages in nfs_page ---
> commit 1fad80f498aa716421accabc5c2572235b589709
> Author: Pranjal Shrivastava <praan@google.com>
> 
> nfs: track number of pinned pages in nfs_page
> 
> This commit adds wb_nr_pinned to struct nfs_page to track the number
> of pinned pages. It updates request creation and cleanup helpers to
> ensure that only primary requests perform the final unpinning operation.
> 
> > diff --git a/fs/nfs/pagelist.c b/fs/nfs/pagelist.c
> > index a562cfe2a126d..b9ccf2a87e3c9 100644
> > --- a/fs/nfs/pagelist.c
> > +++ b/fs/nfs/pagelist.c
> 
> [ ... ]
> 
> > @@ -567,8 +572,8 @@ static void nfs_clear_request(struct nfs_page *req)
> >  
> >  	if (folio != NULL) {
> >  		if (test_and_clear_bit(PG_PINNED, &req->wb_flags)) {
> > -			if (req == req->wb_head)
> > -				unpin_user_folio(folio, 1);
> > +			if (req->wb_nr_pinned > 0)
> > +				unpin_user_folio(folio, req->wb_nr_pinned);
> >  		} else {
> >  			folio_put(folio);
> >  		}
> > @@ -576,8 +581,8 @@ static void nfs_clear_request(struct nfs_page *req)
> >  		clear_bit(PG_FOLIO, &req->wb_flags);
> >  	} else if (page != NULL) {
> >  		if (test_and_clear_bit(PG_PINNED, &req->wb_flags)) {
> > -			if (req == req->wb_head)
> > -				unpin_user_page(page);
> > +			if (req->wb_nr_pinned > 0)
> > +				unpin_user_pages(&page, req->wb_nr_pinned);
> 
> [Severity: Medium]
> Could this lead to an out-of-bounds stack read if wb_nr_pinned is ever
> greater than 1?
> 
> Looking at nfs_clear_request(), page is declared as a single local pointer
> on the stack:
> 
> static void nfs_clear_request(struct nfs_page *req)
> {
> 	...
> 	struct page *page = req->wb_page;
> 
> If req->wb_nr_pinned exceeds 1, unpin_user_pages() will read adjacent stack
> memory to interpret as struct page pointers. While wb_nr_pinned is currently
> hardcoded to 1 when a request is created from a page, passing a dynamically
> loaded length alongside a pointer to a single local stack variable seems
> prone to future regressions.
> 

In this (non-folio) path wb_nr_pinned would always ever be 1. Although,
I think we could use unpin_user_page (singular) here.

Thanks,
Praan

> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260814143255.861084-1-praan@google.com?part=2

  reply	other threads:[~2026-08-14 15:14 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-14 14:32 [PATCH v6 0/5] nfs: modernize direct I/O path Pranjal Shrivastava
2026-08-14 14:32 ` [PATCH v6 1/5] nfs: make nfs_page pin-aware Pranjal Shrivastava
2026-08-14 14:46   ` sashiko-bot
2026-08-14 15:04     ` Pranjal Shrivastava
2026-08-14 14:32 ` [PATCH v6 2/5] nfs: track number of pinned pages in nfs_page Pranjal Shrivastava
2026-08-14 14:47   ` sashiko-bot
2026-08-14 15:14     ` Pranjal Shrivastava [this message]
2026-08-14 14:32 ` [PATCH v6 3/5] nfs: introduce nfs_release_request_list helper Pranjal Shrivastava
2026-08-14 14:38   ` sashiko-bot
2026-08-14 14:32 ` [PATCH v6 4/5] nfs: migrate direct I/O to iov_iter_extract_pages Pranjal Shrivastava
2026-08-14 14:48   ` sashiko-bot
2026-08-14 14:32 ` [PATCH v6 5/5] nfs: introduce nfs_direct_extract_pages helper Pranjal Shrivastava
2026-08-14 14:40   ` sashiko-bot

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=an8w1Zp7YkvkY7S-@google.com \
    --to=praan@google.com \
    --cc=anna@kernel.org \
    --cc=cel@kernel.org \
    --cc=jlayton@kernel.org \
    --cc=linux-pci@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 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.