All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Matthew Wilcox <willy@infradead.org>, Josef Bacik <josef@toxicpanda.com>
Cc: "Joanne Koong" <joannelkoong@gmail.com>,
	"Vlastimil Babka" <vbabka@suse.cz>,
	"Miklos Szeredi" <miklos@szeredi.hu>,
	"Christian Heusel" <christian@heusel.eu>,
	"Miklos Szeredi" <mszeredi@redhat.com>,
	regressions@lists.linux.dev, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-mm <linux-mm@kvack.org>,
	"Mantas Mikulėnas" <grawity@gmail.com>
Subject: Re: [REGRESSION][BISECTED] Crash with Bad page state for FUSE/Flatpak related applications since v6.13
Date: Tue, 11 Feb 2025 09:01:08 -0500	[thread overview]
Message-ID: <ecee2d1392fcb9b075687e7b59ec69057d3c1bb3.camel@kernel.org> (raw)
In-Reply-To: <8a99f6bf3f0b5cb909f11539fb3b0ef0d65b3a73.camel@kernel.org>

On Mon, 2025-02-10 at 17:38 -0500, Jeff Layton wrote:
> On Mon, 2025-02-10 at 20:36 +0000, Matthew Wilcox wrote:
> > On Mon, Feb 10, 2025 at 02:12:35PM -0500, Josef Bacik wrote:
> > > From: Josef Bacik <josef@toxicpanda.com>
> > > Date: Mon, 10 Feb 2025 14:06:40 -0500
> > > Subject: [PATCH] fuse: drop extra put of folio when using pipe splice
> > > 
> > > In 3eab9d7bc2f4 ("fuse: convert readahead to use folios"), I converted
> > > us to using the new folio readahead code, which drops the reference on
> > > the folio once it is locked, using an inferred reference on the folio.
> > > Previously we held a reference on the folio for the entire duration of
> > > the readpages call.
> > > 
> > > This is fine, however I failed to catch the case for splice pipe
> > > responses where we will remove the old folio and splice in the new
> > > folio.  Here we assumed that there is a reference held on the folio for
> > > ap->folios, which is no longer the case.
> > > 
> > > To fix this, simply drop the extra put to keep us consistent with the
> > > non-splice variation.  This will fix the UAF bug that was reported.
> > > 
> > > Link: https://lore.kernel.org/linux-fsdevel/2f681f48-00f5-4e09-8431-2b3dbfaa881e@heusel.eu/
> > > Fixes: 3eab9d7bc2f4 ("fuse: convert readahead to use folios")
> > > Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> > > ---
> > >  fs/fuse/dev.c | 2 --
> > >  1 file changed, 2 deletions(-)
> > > 
> > > diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
> > > index 5b5f789b37eb..5bd6e2e184c0 100644
> > > --- a/fs/fuse/dev.c
> > > +++ b/fs/fuse/dev.c
> > > @@ -918,8 +918,6 @@ static int fuse_try_move_page(struct fuse_copy_state *cs, struct page **pagep)
> > >  	}
> > >  
> > >  	folio_unlock(oldfolio);
> > > -	/* Drop ref for ap->pages[] array */
> > > -	folio_put(oldfolio);
> > >  	cs->len = 0;
> > 
> > But aren't we now leaking a reference to newfolio?  ie shouldn't
> > we also:
> > 
> > -	folio_get(newfolio);
> > 
> > a few lines earlier?
> > 
> 
> 
> I think that ref was leaking without Josef's patch, but your proposed
> fix seems correct to me. There is:
> 
> - 1 reference stolen from the pipe_buffer
> - 1 reference taken for the pagecache in replace_page_cache_folio()
> - the folio_get(newfolio) just after that
> 
> The pagecache ref doesn't count here, and we only need the reference
> that was stolen from the pipe_buffer to replace the one in pagep.

Actually, no. I'm wrong here. A little after the folio_get(newfolio)
call, we do:

        /*
         * Release while we have extra ref on stolen page.  Otherwise
         * anon_pipe_buf_release() might think the page can be reused.
         */
        pipe_buf_release(cs->pipe, buf);

...so that accounts for the extra reference. I think the newfolio
refcounting is correct as-is.
-- 
Jeff Layton <jlayton@kernel.org>

  reply	other threads:[~2025-02-11 14:01 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-06 10:53 [REGRESSION][BISECTED] Crash with Bad page state for FUSE/Flatpak related applications since v6.13 Christian Heusel
2025-02-07  9:34 ` Miklos Szeredi
2025-02-07  9:45   ` Matthew Wilcox
2025-02-07 10:25     ` Vlastimil Babka
2025-02-07 10:43       ` Miklos Szeredi
2025-02-07 10:55         ` Vlastimil Babka
2025-02-07 11:16           ` Bernd Schubert
2025-02-07 18:21             ` Bernd Schubert
2025-02-07 18:40             ` Joanne Koong
2025-02-08  0:02               ` Bernd Schubert
2025-02-08 12:25                 ` Mantas Mikulėnas
2025-02-07 20:35             ` Mantas Mikulėnas
2025-02-07 11:00   ` Mantas Mikulėnas
2025-02-07 16:49   ` Vlastimil Babka
2025-02-07 17:29     ` Josef Bacik
2025-02-07 18:39       ` Vlastimil Babka
2025-02-07 22:29         ` Matthew Wilcox
2025-02-08  0:22         ` Joanne Koong
2025-02-08 10:11           ` Matthew Wilcox
2025-02-08 15:46             ` Joanne Koong
2025-02-10  8:27               ` Vlastimil Babka
2025-02-10 18:13                 ` Joanne Koong
2025-02-10 19:12                   ` Josef Bacik
2025-02-10 19:42                     ` Jeff Layton
2025-02-10 20:36                     ` Matthew Wilcox
2025-02-10 22:38                       ` Jeff Layton
2025-02-11 14:01                         ` Jeff Layton [this message]
2025-02-11 19:23                           ` Joanne Koong
2025-02-11 19:41                             ` Jeff Layton
2025-02-11 21:10                               ` Joanne Koong
2025-02-11 21:01                             ` Vlastimil Babka
2025-02-11 21:21                               ` Joanne Koong
2025-02-10 18:58                 ` Jeff Layton
2025-02-12 18:48               ` Joanne Koong
2025-02-10  8:52   ` [PATCH] fuse: prevent folio use-after-free in readahead Vlastimil Babka

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=ecee2d1392fcb9b075687e7b59ec69057d3c1bb3.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=christian@heusel.eu \
    --cc=grawity@gmail.com \
    --cc=joannelkoong@gmail.com \
    --cc=josef@toxicpanda.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=miklos@szeredi.hu \
    --cc=mszeredi@redhat.com \
    --cc=regressions@lists.linux.dev \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    /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.