All of lore.kernel.org
 help / color / mirror / Atom feed
From: Trond Myklebust <trondmy@kernel.org>
To: liubaolin <liubaolin12138@163.com>, anna@kernel.org
Cc: linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org,
	Baolin Liu <liubaolin@kylinos.cn>
Subject: Re: [PATCH v1] NFS: Fix possible NULL pointer dereference in nfs_inode_remove_request()
Date: Fri, 17 Oct 2025 11:02:52 -0400	[thread overview]
Message-ID: <a0accbb0e4ea7ad101dcaecf6ded576fc0c43a56.camel@kernel.org> (raw)
In-Reply-To: <9243fe19-8e38-43e4-8ea4-077fa4512395@163.com>

On Fri, 2025-10-17 at 14:57 +0800, liubaolin wrote:
> [You don't often get email from liubaolin12138@163.com. Learn why
> this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> > This modification addresses a potential issue detected by Smatch
> > during a scan of the NFS code. After reviewing the relevant code, I
> > confirmed that the change is required to remove the potential risk.
> 
> 

I'm sorry, but I'm still not seeing why we can't just remove the check
for a NULL folio.

Under what circumstances do you see us calling
nfs_inode_remove_request() with a request that has req->wb_head ==
NULL? I'm asking for a concrete example.

> 
> 在 2025/10/13 12:47, Trond Myklebust 写道:
> > On Sun, 2025-10-12 at 16:39 +0800, Baolin Liu wrote:
> > > [You don't often get email from liubaolin12138@163.com. Learn why
> > > this is important at
> > > https://aka.ms/LearnAboutSenderIdentification ]
> > > 
> > > From: Baolin Liu <liubaolin@kylinos.cn>
> > > 
> > > nfs_page_to_folio(req->wb_head) may return NULL in certain
> > > conditions,
> > > but the function dereferences folio->mapping and calls
> > > folio_end_dropbehind(folio) unconditionally. This may cause a
> > > NULL
> > > pointer dereference crash.
> > > 
> > > Fix this by checking folio before using it or calling
> > > folio_end_dropbehind().
> > > 
> > > Signed-off-by: Baolin Liu <liubaolin@kylinos.cn>
> > > ---
> > >   fs/nfs/write.c | 11 ++++++-----
> > >   1 file changed, 6 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/fs/nfs/write.c b/fs/nfs/write.c
> > > index 0fb6905736d5..e148308c1923 100644
> > > --- a/fs/nfs/write.c
> > > +++ b/fs/nfs/write.c
> > > @@ -739,17 +739,18 @@ static void nfs_inode_remove_request(struct
> > > nfs_page *req)
> > >          nfs_page_group_lock(req);
> > >          if (nfs_page_group_sync_on_bit_locked(req, PG_REMOVE)) {
> > >                  struct folio *folio = nfs_page_to_folio(req-
> > > > wb_head);
> > > -               struct address_space *mapping = folio->mapping;
> > > 
> > > -               spin_lock(&mapping->i_private_lock);
> > >                  if (likely(folio)) {
> > > +                       struct address_space *mapping = folio-
> > > > mapping;
> > > +
> > > +                       spin_lock(&mapping->i_private_lock);
> > >                          folio->private = NULL;
> > >                          folio_clear_private(folio);
> > >                          clear_bit(PG_MAPPED, &req->wb_head-
> > > > wb_flags);
> > > -               }
> > > -               spin_unlock(&mapping->i_private_lock);
> > > +                       spin_unlock(&mapping->i_private_lock);
> > > 
> > > -               folio_end_dropbehind(folio);
> > > +                       folio_end_dropbehind(folio);
> > > +               }
> > >          }
> > >          nfs_page_group_unlock(req);
> > > 
> > > --
> > > 2.39.2
> > > 
> > 
> > What reason is there to believe that we can ever call
> > nfs_inode_remove_request() with a NULL value for req->wb_head-
> > > wb_folio, or even with a NULL value for req->wb_head->wb_folio-
> > > mapping?
> > 
> > 
> 

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trondmy@kernel.org, trond.myklebust@hammerspace.com

  reply	other threads:[~2025-10-17 15:02 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-12  8:39 [PATCH v1] NFS: Fix possible NULL pointer dereference in nfs_inode_remove_request() Baolin Liu
2025-10-12 11:21 ` [PATCH] " Markus Elfring
2025-10-13  4:47 ` [PATCH v1] " Trond Myklebust
2025-10-17  6:57   ` liubaolin
2025-10-17 15:02     ` Trond Myklebust [this message]
2025-10-22  2:44       ` liubaolin
2025-10-22  3:15         ` Trond Myklebust
2025-10-22  3:26           ` Trond Myklebust
2025-10-22  7:34           ` Dan Carpenter
2025-10-22  7:36             ` Dan Carpenter

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=a0accbb0e4ea7ad101dcaecf6ded576fc0c43a56.camel@kernel.org \
    --to=trondmy@kernel.org \
    --cc=anna@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=liubaolin12138@163.com \
    --cc=liubaolin@kylinos.cn \
    /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.