From: Jann Horn <jann@thejh.net>
To: Nikhilesh Reddy <reddyn@codeaurora.org>
Cc: torvalds@linux-foundation.org, Miklos Szeredi <miklos@szeredi.hu>,
fuse-devel <fuse-devel@lists.sourceforge.net>,
linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
gregkh@linuxfoundation.org, linux-fsdevel@vger.kernel.org,
viro@zeniv.linux.org.uk, Richard Weinberger <richard@nod.at>,
"Theodore Ts'o" <tytso@mit.edu>,
jack@suse.cz, Antonio SJ Musumeci <trapexit@spawn.link>,
sven.utcke@gmx.de, Nikolaus Rath <nikolaus@rath.org>,
Jann Horn <jannhorn@googlemail.com>, Mike Shal <marfey@gmail.com>
Subject: Re: [PATCH v5] fuse: Add support for passthrough read/write
Date: Wed, 3 Feb 2016 20:56:44 +0100 [thread overview]
Message-ID: <20160203195644.GB991@pc.thejh.net> (raw)
In-Reply-To: <56B24F7C.4060703@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 3565 bytes --]
On Wed, Feb 03, 2016 at 11:05:32AM -0800, Nikhilesh Reddy wrote:
> On 02/01/2016 11:45 AM, Jann Horn wrote:
> >On Mon, Feb 01, 2016 at 11:28:51AM -0800, Nikhilesh Reddy wrote:
> >>On Mon 01 Feb 2016 11:15:56 AM PST, Jann Horn wrote:
> >>>On Mon, Feb 01, 2016 at 10:56:27AM -0800, Nikhilesh Reddy wrote:
> >>>>diff --git a/fs/fuse/passthrough.c b/fs/fuse/passthrough.c
> >>>[...]
> >>>>+static ssize_t fuse_passthrough_read_write_iter(struct kiocb *iocb,
> >>>>+ struct iov_iter *iter, int do_write)
> >>>>+{
> >>>>+ ssize_t ret_val;
> >>>>+ struct fuse_file *ff;
> >>>>+ struct file *fuse_file, *passthrough_filp;
> >>>>+ struct inode *fuse_inode, *passthrough_inode;
> >>>>+
> >>>>+ ff = iocb->ki_filp->private_data;
> >>>>+ fuse_file = iocb->ki_filp;
> >>>>+ passthrough_filp = ff->passthrough_filp;
> >>>>+
> >>>>+ /* lock passthrough file to prevent it from being released */
> >>>>+ get_file(passthrough_filp);
> >>>>+ iocb->ki_filp = passthrough_filp;
> >>>>+ fuse_inode = fuse_file->f_path.dentry->d_inode;
> >>>>+ passthrough_inode = file_inode(passthrough_filp);
> >>>>+
> >>>>+ if (do_write) {
> >>>>+ if (!passthrough_filp->f_op->write_iter)
> >>>>+ return -EIO;
> >>>>+ ret_val = passthrough_filp->f_op->write_iter(iocb, iter);
> >>>>+
> >>>>+ if (ret_val >= 0 || ret_val == -EIOCBQUEUED) {
> >>>>+ fsstack_copy_inode_size(fuse_inode, passthrough_inode);
> >>>>+ fsstack_copy_attr_times(fuse_inode, passthrough_inode);
> >>>>+ }
> >>>>+ } else {
> >>>>+ if (!passthrough_filp->f_op->read_iter)
> >>>>+ return -EIO;
> >>>>+ ret_val = passthrough_filp->f_op->read_iter(iocb, iter);
> >>>>+ if (ret_val >= 0 || ret_val == -EIOCBQUEUED)
> >>>>+ fsstack_copy_attr_atime(fuse_inode, passthrough_inode);
> >>>>+ }
> >>>>+
> >>>>+ iocb->ki_filp = fuse_file;
> >>>>+
> >>>>+ /* unlock passthrough file */
> >>>>+ fput(passthrough_filp);
> >>>
> >>>Why the get_file() and fput() in this method? This doesn't look right. There
> >>>is no lock you're releasing between get_file() and fput(). What are they
> >>>intended for?
> >>
> >>Hi
> >>
> >>Thanks for reviewing the code.
> >>
> >>The passthrough file could be released under our feet say if the userspace
> >>fuse daemon crashed or was killed ( while we are processing the read or the
> >>write) causing bad things to happen.
> >>The calls here are to increase the count temporarily and then decrease it
> >>so that we dont release in the middle of a write and everything is
> >>gracefully handled...
> >>
> >>I have a comment right before the get_file call above saying the same thing.
> >>Please let me know if you have any more questions.
> >
> >If that is the case, why can't the passthrough file be released before the
> >get_file() call, e.g. while the core processing the filesystem read request
> >is entering fuse_passthrough_read_write_iter()?
> >
> >As far as I can tell, you can drop the get_file() and fput() calls.
> >fuse_setup_passthrough() already took a reference to the file for you, that
> >reference can only be dropped in fuse_passthrough_release(), and the VFS
> >ensures that no release call happens while a read or write is pending.
> >
> I just feel uncomfortable with dropping them. I thought they could be
> released ( i/o ) takes longer than the actual execution... but if i can be
> sure of it then maybe..
These get_file() and fput() calls aren't useful.
And I think they can lead to a reference count leak, which would lead to a
use-after-free vulnerability on 32bit kernels, because you forgot to fput()
in the error cases where you return -EIO.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2016-02-03 19:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-01 18:56 Nikhilesh Reddy
2016-02-01 19:15 ` Jann Horn
2016-02-01 19:28 ` Nikhilesh Reddy
2016-02-01 19:45 ` Jann Horn
2016-02-03 19:05 ` Nikhilesh Reddy
2016-02-03 19:56 ` Jann Horn [this message]
2016-02-02 8:10 ` Jann Horn
2016-02-03 19:05 ` Nikhilesh Reddy
2016-02-03 19:53 ` Jann Horn
2016-02-03 20:16 ` Nikhilesh Reddy
2016-02-03 20:42 ` Jann Horn
2016-03-04 12:23 ` [fuse-devel] " Andrew Karpow
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=20160203195644.GB991@pc.thejh.net \
--to=jann@thejh.net \
--cc=fuse-devel@lists.sourceforge.net \
--cc=gregkh@linuxfoundation.org \
--cc=jack@suse.cz \
--cc=jannhorn@googlemail.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marfey@gmail.com \
--cc=miklos@szeredi.hu \
--cc=nikolaus@rath.org \
--cc=reddyn@codeaurora.org \
--cc=richard@nod.at \
--cc=sven.utcke@gmx.de \
--cc=torvalds@linux-foundation.org \
--cc=trapexit@spawn.link \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
/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
all inboxes | Powered by JetHome®