| Message ID | 20190112013905.9551-1-jannh@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | fuse: call pipe_buf_release() under pipe lock | expand |
diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c index a5e516a40e7a..ef00a8277824 100644 --- a/fs/fuse/dev.c +++ b/fs/fuse/dev.c @@ -2077,8 +2077,10 @@ static ssize_t fuse_dev_splice_write(struct pipe_inode_info *pipe, ret = fuse_dev_do_write(fud, &cs, len); + pipe_lock(pipe); for (idx = 0; idx < nbuf; idx++) pipe_buf_release(pipe, &bufs[idx]); + pipe_unlock(pipe); out: kvfree(bufs);
Some of the pipe_buf_release() handlers seem to assume that the pipe is locked - in particular, anon_pipe_buf_release() accesses pipe->tmp_page without taking any extra locks. From a glance through the callers of pipe_buf_release(), it looks like FUSE is the only one that calls pipe_buf_release() without having the pipe locked. This bug should only lead to a memory leak, nothing terrible. Fixes: dd3bb14f44a6 ("fuse: support splice() writing to fuse device") Cc: stable@vger.kernel.org Signed-off-by: Jann Horn <jannh@google.com> --- Warning: I've only found this by inspection, I haven't actually tested it. If someone familiar with the pipe and splice code (Al Viro? Eric Biggers?) could comment on this and double-check that this is actually a real issue, that'd be nice. Also, if it's a real issue, maybe there should be some more lockdep checks sprayed across the pipe code... fs/fuse/dev.c | 2 ++ 1 file changed, 2 insertions(+)