From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2A99CC433B4 for ; Fri, 21 May 2021 08:15:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 07435613B6 for ; Fri, 21 May 2021 08:15:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230320AbhEUIRD convert rfc822-to-8bit (ORCPT ); Fri, 21 May 2021 04:17:03 -0400 Received: from us-smtp-delivery-44.mimecast.com ([205.139.111.44]:32655 "EHLO us-smtp-delivery-44.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229629AbhEUIRC (ORCPT ); Fri, 21 May 2021 04:17:02 -0400 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-134-P7MMZ4skNEasB_Ci5O7ioQ-1; Fri, 21 May 2021 04:15:35 -0400 X-MC-Unique: P7MMZ4skNEasB_Ci5O7ioQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9FD3F107ACCD; Fri, 21 May 2021 08:15:34 +0000 (UTC) Received: from bahia.lan (ovpn-112-49.ams2.redhat.com [10.36.112.49]) by smtp.corp.redhat.com (Postfix) with ESMTP id B74C65C8A8; Fri, 21 May 2021 08:15:24 +0000 (UTC) Date: Fri, 21 May 2021 10:15:23 +0200 From: Greg Kurz To: Miklos Szeredi Cc: Al Viro , virtualization@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, virtio-fs-list , Stefan Hajnoczi , Max Reitz , Vivek Goyal Subject: Re: [PATCH v4 1/5] fuse: Fix leak in fuse_dentry_automount() error path Message-ID: <20210521101523.4f276dac@bahia.lan> In-Reply-To: References: <20210520154654.1791183-1-groug@kaod.org> <20210520154654.1791183-2-groug@kaod.org> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=groug@kaod.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: kaod.org Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 21 May 2021 09:54:19 +0200 Miklos Szeredi wrote: > On Thu, 20 May 2021 at 21:45, Al Viro wrote: > > > > On Thu, May 20, 2021 at 05:46:50PM +0200, Greg Kurz wrote: > > > Some rollback was forgotten during the addition of crossmounts. > > > > Have you actually tested that? Because I strongly suspect that > > by that point the ownership of fc and fm is with sb and those > > should be taken care of by deactivate_locked_super(). > > Not quite. Patch looks correct because destruction of fm is done in > fuse_put_super(), which only gets called if the sb initialization gets > as far as setting up sb->s_root, which only happens after the > successful fuse_fill_super_submount() call in this case. > > Doing the destruction from the various ->kill_sb() instances instead > of from ->put_super() would also fix this, but I'm not quite sure that > that would be any cleaner. > As saying in the answer I've just posted, a failure in fuse_fill_super_submount() causes an actual crash because fuse_mount_remove() logically assumes fm to already be in fc->mounts, which isn't the case at this point. In the root mount case, this is handled by taking back the ownership on fm, i.e. do the rollback *and* clear sb->s_fs_info. It seems that the same should be done for submounts. > Thanks, > Miklos From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2C0F9C433ED for ; Fri, 21 May 2021 08:15:44 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CB5D2613AC for ; Fri, 21 May 2021 08:15:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CB5D2613AC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kaod.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=virtualization-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 7AEE784580; Fri, 21 May 2021 08:15:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Agt38LdtTqvo; Fri, 21 May 2021 08:15:42 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp1.osuosl.org (Postfix) with ESMTP id 3007A84549; Fri, 21 May 2021 08:15:42 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id E1EB8C000D; Fri, 21 May 2021 08:15:41 +0000 (UTC) Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 17FFFC0001 for ; Fri, 21 May 2021 08:15:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id F2AD96073D for ; Fri, 21 May 2021 08:15:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zwYjwebquFw for ; Fri, 21 May 2021 08:15:40 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from us-smtp-delivery-44.mimecast.com (us-smtp-delivery-44.mimecast.com [205.139.111.44]) by smtp3.osuosl.org (Postfix) with ESMTPS id 51D876072D for ; Fri, 21 May 2021 08:15:40 +0000 (UTC) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-134-P7MMZ4skNEasB_Ci5O7ioQ-1; Fri, 21 May 2021 04:15:35 -0400 X-MC-Unique: P7MMZ4skNEasB_Ci5O7ioQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9FD3F107ACCD; Fri, 21 May 2021 08:15:34 +0000 (UTC) Received: from bahia.lan (ovpn-112-49.ams2.redhat.com [10.36.112.49]) by smtp.corp.redhat.com (Postfix) with ESMTP id B74C65C8A8; Fri, 21 May 2021 08:15:24 +0000 (UTC) Date: Fri, 21 May 2021 10:15:23 +0200 From: Greg Kurz To: Miklos Szeredi Subject: Re: [PATCH v4 1/5] fuse: Fix leak in fuse_dentry_automount() error path Message-ID: <20210521101523.4f276dac@bahia.lan> In-Reply-To: References: <20210520154654.1791183-1-groug@kaod.org> <20210520154654.1791183-2-groug@kaod.org> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=groug@kaod.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: kaod.org Cc: linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, virtio-fs-list , Al Viro , Stefan Hajnoczi , linux-fsdevel@vger.kernel.org, Max Reitz , Vivek Goyal X-BeenThere: virtualization@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Linux virtualization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: virtualization-bounces@lists.linux-foundation.org Sender: "Virtualization" On Fri, 21 May 2021 09:54:19 +0200 Miklos Szeredi wrote: > On Thu, 20 May 2021 at 21:45, Al Viro wrote: > > > > On Thu, May 20, 2021 at 05:46:50PM +0200, Greg Kurz wrote: > > > Some rollback was forgotten during the addition of crossmounts. > > > > Have you actually tested that? Because I strongly suspect that > > by that point the ownership of fc and fm is with sb and those > > should be taken care of by deactivate_locked_super(). > > Not quite. Patch looks correct because destruction of fm is done in > fuse_put_super(), which only gets called if the sb initialization gets > as far as setting up sb->s_root, which only happens after the > successful fuse_fill_super_submount() call in this case. > > Doing the destruction from the various ->kill_sb() instances instead > of from ->put_super() would also fix this, but I'm not quite sure that > that would be any cleaner. > As saying in the answer I've just posted, a failure in fuse_fill_super_submount() causes an actual crash because fuse_mount_remove() logically assumes fm to already be in fc->mounts, which isn't the case at this point. In the root mount case, this is handled by taking back the ownership on fm, i.e. do the rollback *and* clear sb->s_fs_info. It seems that the same should be done for submounts. > Thanks, > Miklos _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 21 May 2021 10:15:23 +0200 From: Greg Kurz Message-ID: <20210521101523.4f276dac@bahia.lan> In-Reply-To: References: <20210520154654.1791183-1-groug@kaod.org> <20210520154654.1791183-2-groug@kaod.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Virtio-fs] [PATCH v4 1/5] fuse: Fix leak in fuse_dentry_automount() error path List-Id: Development discussions about virtio-fs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Miklos Szeredi Cc: Stefan, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, virtio-fs-list , Al Viro , linux-fsdevel@vger.kernel.org, Max Reitz , Vivek Goyal On Fri, 21 May 2021 09:54:19 +0200 Miklos Szeredi wrote: > On Thu, 20 May 2021 at 21:45, Al Viro wrote: > > > > On Thu, May 20, 2021 at 05:46:50PM +0200, Greg Kurz wrote: > > > Some rollback was forgotten during the addition of crossmounts. > > > > Have you actually tested that? Because I strongly suspect that > > by that point the ownership of fc and fm is with sb and those > > should be taken care of by deactivate_locked_super(). > > Not quite. Patch looks correct because destruction of fm is done in > fuse_put_super(), which only gets called if the sb initialization gets > as far as setting up sb->s_root, which only happens after the > successful fuse_fill_super_submount() call in this case. > > Doing the destruction from the various ->kill_sb() instances instead > of from ->put_super() would also fix this, but I'm not quite sure that > that would be any cleaner. > As saying in the answer I've just posted, a failure in fuse_fill_super_submount() causes an actual crash because fuse_mount_remove() logically assumes fm to already be in fc->mounts, which isn't the case at this point. In the root mount case, this is handled by taking back the ownership on fm, i.e. do the rollback *and* clear sb->s_fs_info. It seems that the same should be done for submounts. > Thanks, > Miklos