kernel/git/stable/linux.git/fs/fuse/cuse.c, branch linux-4.4.y

cuse: prevent clone

2021-05-22T08:38:27+00:00

[ Upstream commit 8217673d07256b22881127bf50dce874d0e51653 ] For cloned connections cuse_channel_release() will be called more than once, resulting in use after free. Prevent device cloning for CUSE, which does not make sense at this point, and highly unlikely to be used in real life. Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin

fuse: fix memleak in cuse_channel_open

2019-10-17T20:40:55+00:00

[ Upstream commit 9ad09b1976c562061636ff1e01bfc3a57aebe56b ] If cuse_send_init fails, need to fuse_conn_put cc->fc. cuse_channel_open->fuse_conn_init->refcount_set(&fc->count, 1) ->fuse_dev_alloc->fuse_conn_get ->fuse_dev_free->fuse_conn_put Fixes: cc080e9e9be1 ("fuse: introduce per-instance fuse_dev structure") Reported-by: Hulk Robot Signed-off-by: zhengbin Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin

fuse: Add reference counting for fuse_io_priv

2016-04-12T16:08:58+00:00

commit 744742d692e37ad5c20630e57d526c8f2e2fe3c9 upstream. The 'reqs' member of fuse_io_priv serves two purposes. First is to track the number of oustanding async requests to the server and to signal that the io request is completed. The second is to be a reference count on the structure to know when it can be freed. For sync io requests these purposes can be at odds. fuse_direct_IO() wants to block until the request is done, and since the signal is sent when 'reqs' reaches 0 it cannot keep a reference to the object. Yet it needs to use the object after the userspace server has completed processing requests. This leads to some handshaking and special casing that it needlessly complicated and responsible for at least one race condition. It's much cleaner and safer to maintain a separate reference count for the object lifecycle and to let 'reqs' just be a count of outstanding requests to the userspace server. Then we can know for sure when it is safe to free the object without any handshaking or special cases. The catch here is that most of the time these objects are stack allocated and should not be freed. Initializing these objects with a single reference that is never released prevents accidental attempts to free the objects. Fixes: 9d5722b7777e ("fuse: handle synchronous iocbs internally") Signed-off-by: Seth Forshee Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman

cuse: fix memory leak

2015-11-10T09:32:36+00:00

The problem is that fuse_dev_alloc() acquires an extra reference to cc.fc, and the original ref count is never dropped. Reported-by: Colin Ian King Signed-off-by: Miklos Szeredi Fixes: cc080e9e9be1 ("fuse: introduce per-instance fuse_dev structure") Cc: # v4.2+

fuse: introduce per-instance fuse_dev structure

2015-07-01T14:26:08+00:00

Allow fuse device clones to refer to be distinguished. This patch just adds the infrastructure by associating a separate "struct fuse_dev" with each clone. Signed-off-by: Miklos Szeredi Reviewed-by: Ashish Samant

fuse: duplicate ->connected in iqueue

2015-07-01T14:26:01+00:00

This will allow checking ->connected just with the input queue lock. Signed-off-by: Miklos Szeredi Reviewed-by: Ashish Samant

make new_sync_{read,write}() static

2015-04-12T02:29:40+00:00

All places outside of core VFS that checked ->read and ->write for being NULL or called the methods directly are gone now, so NULL {read,write} with non-NULL {read,write}_iter will do the right thing in all cases. Signed-off-by: Al Viro

cuse: switch to iov_iter

2015-04-12T02:27:52+00:00

Signed-off-by: Al Viro

fs: move struct kiocb to fs.h

2015-03-26T00:28:11+00:00

struct kiocb now is a generic I/O container, so move it to fs.h. Also do a #include diet for aio.h while we're at it. Signed-off-by: Christoph Hellwig Signed-off-by: Al Viro

fuse: flush requests on umount

2014-12-12T08:49:04+00:00

Use fuse_abort_conn() instead of fuse_conn_kill() in fuse_put_super(). This flushes and aborts requests still on any queues. But since we've already reset fc->connected, those requests would not be useful anyway and would be flushed when the fuse device is closed. Next patches will rely on requests being flushed before the superblock is destroyed. Use fuse_abort_conn() in cuse_process_init_reply() too, since it makes no difference there, and we can get rid of fuse_conn_kill(). Signed-off-by: Miklos Szeredi