From patchwork Sat Jan 12 01:39:05 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jann Horn X-Patchwork-Id: 10760841 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id E74BB91E for ; Sat, 12 Jan 2019 01:39:22 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id CABFE29D78 for ; Sat, 12 Jan 2019 01:39:22 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id A5A3F29D93; Sat, 12 Jan 2019 01:39:22 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.5 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, USER_IN_DEF_DKIM_WL autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4D1B529D78 for ; Sat, 12 Jan 2019 01:39:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726383AbfALBjV (ORCPT ); Fri, 11 Jan 2019 20:39:21 -0500 Received: from mail-yb1-f202.google.com ([209.85.219.202]:52435 "EHLO mail-yb1-f202.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726282AbfALBjV (ORCPT ); Fri, 11 Jan 2019 20:39:21 -0500 Received: by mail-yb1-f202.google.com with SMTP id n8so8421176ybm.19 for ; Fri, 11 Jan 2019 17:39:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:message-id:mime-version:subject:from:to:cc; bh=c+vkKLnP8UTQKHp/ytFml/xIiJOKbPcmLLGcQ4OUJ/A=; b=qzaeMpNWEwn2eCjG7rWlT4hQsDWRCCjCCGJesyaCtvSDz7KcD1+Oi+B0UPSRTCXfj2 gf3QRxDkdbtmYU0hzEWRZdO/SFofes1Zoen5yP1MFI0rYPIPlmVlx1Mh/GxnElcgyVwe hQC5vVHm0RejVTjijOo/H4+bIiV/M/N2IiYM7NzQ50fhih6QLhfVHatU/xrl/lu7UErW Mkq6SvwfOkFCCk2qWw/j1JIzU73/GJqqMOUrXzOEGeGg5Q3UcyqAj9fgRUKEhCGxDIGl Y1bCXoeO4uS1YL/YhKZbrpQCxilIuV6CuYjtRn60zqFSga0/BUBcoXZpIXFSUAJLR22d dnDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:message-id:mime-version:subject:from:to:cc; bh=c+vkKLnP8UTQKHp/ytFml/xIiJOKbPcmLLGcQ4OUJ/A=; b=L1yuyKK8ZdmnHaREBuZQxZnZHVKbpSs4+/A7T4P0cEnyYuUQeceiAcY3Yf3+f2fdhd 3pljFOCfDSeT72PeXMt9P0CuC0Se3ssdJrRYyZeLlhZQ/2I6KP0XvRFQ506UGBZPB9UE Hb1NK9R3IqiiYRHAZLltLpNRFh9JOCyFsaxjs4lToETy27lzFMV2IkDw22wFMwKqMYwQ yR8S0JuUPRMV/Eoy0aGz7QVaRqVfdaQdFHaRhyhptNqxmyn4uzbdEK5Z7HQQKyQgK4+d TYifANklwi+Odg4TIOY2Hil0BUSqd8D/wz9O1ljq/06YvuIenFMGXZAj+MyrIkXR7r9b 7YmQ== X-Gm-Message-State: AJcUukd/wNdNCPUaInOc9lO88LNEhXIaAIRFyT8O/B24KDyjh6Bx4BHX oVs1FtyT21RsjfxdQuhJG7JYmXgF8Q== X-Google-Smtp-Source: ALg8bN5CK/MIfptzdfwHv8TnDVZUOLkGA4lIgjAHVE3Lnty8H0Jrna57EfSryMrcvITxzOertcG++9U8Bg== X-Received: by 2002:a81:6c4e:: with SMTP id h75mr1604073ywc.12.1547257160377; Fri, 11 Jan 2019 17:39:20 -0800 (PST) Date: Sat, 12 Jan 2019 02:39:05 +0100 Message-Id: <20190112013905.9551-1-jannh@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.20.1.97.g81188d93c3-goog Subject: [PATCH] fuse: call pipe_buf_release() under pipe lock From: Jann Horn To: Miklos Szeredi , Al Viro , Eric Biggers , jannh@google.com Cc: linux-fsdevel@vger.kernel.org Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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 --- 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(+) 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);