2024-03-05 23:37:56

by Stephen Rothwell

[permalink] [raw]
Subject: linux-next: manual merge of the fuse tree with Linus' tree

Hi all,

Today's linux-next merge of the fuse tree got a conflict in:

fs/fuse/inode.c

between commit:

053fc4f755ad ("fuse: fix UAF in rcu pathwalks")

from Linus' tree and commit:

44350256ab94 ("fuse: implement ioctls to manage backing files")

from the fuse tree.

I fixed it up (I think? see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

--
Cheers,
Stephen Rothwell

diff --cc fs/fuse/inode.c
index 516ea2979a90,02869edf72f3..000000000000
--- a/fs/fuse/inode.c
+++ b/fs/fuse/inode.c
@@@ -930,14 -942,6 +942,16 @@@ void fuse_conn_init(struct fuse_conn *f
}
EXPORT_SYMBOL_GPL(fuse_conn_init);

+static void delayed_release(struct rcu_head *p)
+{
+ struct fuse_conn *fc = container_of(p, struct fuse_conn, rcu);
+
+ put_user_ns(fc->user_ns);
++ if (IS_ENABLED(CONFIG_FUSE_PASSTHROUGH))
++ fuse_backing_files_free(fc);
+ fc->release(fc);
+}
+
void fuse_conn_put(struct fuse_conn *fc)
{
if (refcount_dec_and_test(&fc->count)) {


Attachments:
(No filename) (499.00 B)
OpenPGP digital signature

2024-03-07 14:16:46

by Miklos Szeredi

[permalink] [raw]
Subject: Re: linux-next: manual merge of the fuse tree with Linus' tree

On Wed, 6 Mar 2024 at 00:34, Stephen Rothwell <[email protected]> wrote:

> diff --cc fs/fuse/inode.c
> index 516ea2979a90,02869edf72f3..000000000000
> --- a/fs/fuse/inode.c
> +++ b/fs/fuse/inode.c
> @@@ -930,14 -942,6 +942,16 @@@ void fuse_conn_init(struct fuse_conn *f
> }
> EXPORT_SYMBOL_GPL(fuse_conn_init);
>
> +static void delayed_release(struct rcu_head *p)
> +{
> + struct fuse_conn *fc = container_of(p, struct fuse_conn, rcu);
> +
> + put_user_ns(fc->user_ns);
> ++ if (IS_ENABLED(CONFIG_FUSE_PASSTHROUGH))
> ++ fuse_backing_files_free(fc);
> + fc->release(fc);
> +}
> +

fuse_backing_files_free() doesn't need to be called after an RCU
delay, so it should be resolved like this:

diff --cc fs/fuse/inode.c
index 516ea2979a90,02869edf72f3..000000000000
--- a/fs/fuse/inode.c
+++ b/fs/fuse/inode.c
@@@ -954,7 -959,9 +966,9 @@@ void fuse_conn_put(struct fuse_conn *fc
WARN_ON(atomic_read(&bucket->count) != 1);
kfree(bucket);
}
+ if (IS_ENABLED(CONFIG_FUSE_PASSTHROUGH))
+ fuse_backing_files_free(fc);
- fc->release(fc);
+ call_rcu(&fc->rcu, delayed_release);
}
}
EXPORT_SYMBOL_GPL(fuse_conn_put);

Thanks,
Miklos

2024-03-07 21:34:30

by Stephen Rothwell

[permalink] [raw]
Subject: Re: linux-next: manual merge of the fuse tree with Linus' tree

Hi Miklos,

On Thu, 7 Mar 2024 15:16:00 +0100 Miklos Szeredi <[email protected]> wrote:
>
> On Wed, 6 Mar 2024 at 00:34, Stephen Rothwell <[email protected]> wrote:
>
> > diff --cc fs/fuse/inode.c
> > index 516ea2979a90,02869edf72f3..000000000000
> > --- a/fs/fuse/inode.c
> > +++ b/fs/fuse/inode.c
> > @@@ -930,14 -942,6 +942,16 @@@ void fuse_conn_init(struct fuse_conn *f
> > }
> > EXPORT_SYMBOL_GPL(fuse_conn_init);
> >
> > +static void delayed_release(struct rcu_head *p)
> > +{
> > + struct fuse_conn *fc = container_of(p, struct fuse_conn, rcu);
> > +
> > + put_user_ns(fc->user_ns);
> > ++ if (IS_ENABLED(CONFIG_FUSE_PASSTHROUGH))
> > ++ fuse_backing_files_free(fc);
> > + fc->release(fc);
> > +}
> > +
>
> fuse_backing_files_free() doesn't need to be called after an RCU
> delay, so it should be resolved like this:
>
> diff --cc fs/fuse/inode.c
> index 516ea2979a90,02869edf72f3..000000000000
> --- a/fs/fuse/inode.c
> +++ b/fs/fuse/inode.c
> @@@ -954,7 -959,9 +966,9 @@@ void fuse_conn_put(struct fuse_conn *fc
> WARN_ON(atomic_read(&bucket->count) != 1);
> kfree(bucket);
> }
> + if (IS_ENABLED(CONFIG_FUSE_PASSTHROUGH))
> + fuse_backing_files_free(fc);
> - fc->release(fc);
> + call_rcu(&fc->rcu, delayed_release);
> }
> }
> EXPORT_SYMBOL_GPL(fuse_conn_put);

Thanks, I will do that from today.

--
Cheers,
Stephen Rothwell


Attachments:
(No filename) (499.00 B)
OpenPGP digital signature