Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2229449imm; Mon, 28 May 2018 04:22:33 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpBuvY6TzYbH2p2Cks6Tw3Bc2rrQl9cmFPvBW624HGSNPs9zy3SwDLPz2fGRfWxGY1oVIT3 X-Received: by 2002:a17:902:bd46:: with SMTP id b6-v6mr13290780plx.170.1527506553506; Mon, 28 May 2018 04:22:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527506553; cv=none; d=google.com; s=arc-20160816; b=l0NVKqmi+ypC27zzFgkp4dUrVPSW/R1dxbF6m1Jrl1xf0CpJtEvnrCwe6jEB0SRGpJ 0btmp+fJnxbzKEx/pFkRdTnui/C4MYAH5gxsbargxtCSSDfMGomazK1suP59X3aLVPRI 6J2yIcHt88pEBn5IsEcANkVYIRGjzWHJNeEEanNV9UQYh5eJNpNcHjJNOjfl5UaVxzrd MAKxHMrkTSmCy7+Mnfcj7QVYGaZ/GTJLAvckzbiZwGWMswCi3zMe8gNNDkQ7un4+Ps/J wLEAhJZSGCS32r2UUsAi99IHVzURIgPmysCW/bcak6QGDd56QLbuyZuQ15G9CbgvR7RK glow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from:dkim-signature :arc-authentication-results; bh=vO16dGuu0i9osmovuLOx1c1zDXvw6kg1eWjqCxbORa4=; b=LBNG2tHZqhDRLZh/DzisR9mC2jxh43El+CQOa7nOPWN9SGJ+UkoIYbxHOh4RP6mWRM hY4mKnX7zv0Jf5ky6Ke7WcAApZWaaqwcOj1tz6Fytp3PgukUJbtIaiQpeXcTyIbhyuYn N5EX5Khr3r1PRPXwl22qjbFqgl6eXkD3jFJE/JmQvVi/0Rl1wSaVYOcdAgt73Yy2XMel /uqCgamNPws90AUiL1QkKdbLG4nmDnyAtgtWEbtfXo3NCFNQAsqVVRhbUePFeNBSzwPh GhK5r6a+xA5owavALHNbVSNw2kgpxaz+em8T8qVia/VdskiesxAPmrzvaaCklUZ6lqD+ QFEA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=A4+3YBp5; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 18-v6si6864054pft.235.2018.05.28.04.22.18; Mon, 28 May 2018 04:22:33 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=A4+3YBp5; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1424875AbeE1LVa (ORCPT + 99 others); Mon, 28 May 2018 07:21:30 -0400 Received: from mail.kernel.org ([198.145.29.99]:38584 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1424869AbeE1LVY (ORCPT ); Mon, 28 May 2018 07:21:24 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 930FC20883; Mon, 28 May 2018 11:21:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1527506484; bh=iKkK/g8uRIqMI8wFfGvS5+ffscGwaSf9f6TceYvaGMQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=A4+3YBp5uwwX+wEtKlDQGVgp6N6TOOWzQkTTAOYlWQ7uUL+JuCaWNX9UoBUt1svPf 9BTUvXnppW9EiicUp/9a67ldlnmVjhBDzwdOux4PrDVBnV3qloTkaBZMW1HBMLcStl YZu1G9Bq34i0j72K7zp6n5ntBbPvLU85blcfUxBQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dave Chinner , Al Viro Subject: [PATCH 4.16 010/272] fs: dont scan the inode cache before SB_BORN is set Date: Mon, 28 May 2018 12:00:43 +0200 Message-Id: <20180528100241.116317324@linuxfoundation.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180528100240.256525891@linuxfoundation.org> References: <20180528100240.256525891@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.16-stable review patch. If anyone has any objections, please let me know. ------------------ From: Dave Chinner commit 79f546a696bff2590169fb5684e23d65f4d9f591 upstream. We recently had an oops reported on a 4.14 kernel in xfs_reclaim_inodes_count() where sb->s_fs_info pointed to garbage and so the m_perag_tree lookup walked into lala land. It produces an oops down this path during the failed mount: radix_tree_gang_lookup_tag+0xc4/0x130 xfs_perag_get_tag+0x37/0xf0 xfs_reclaim_inodes_count+0x32/0x40 xfs_fs_nr_cached_objects+0x11/0x20 super_cache_count+0x35/0xc0 shrink_slab.part.66+0xb1/0x370 shrink_node+0x7e/0x1a0 try_to_free_pages+0x199/0x470 __alloc_pages_slowpath+0x3a1/0xd20 __alloc_pages_nodemask+0x1c3/0x200 cache_grow_begin+0x20b/0x2e0 fallback_alloc+0x160/0x200 kmem_cache_alloc+0x111/0x4e0 The problem is that the superblock shrinker is running before the filesystem structures it depends on have been fully set up. i.e. the shrinker is registered in sget(), before ->fill_super() has been called, and the shrinker can call into the filesystem before fill_super() does it's setup work. Essentially we are exposed to both use-after-free and use-before-initialisation bugs here. To fix this, add a check for the SB_BORN flag in super_cache_count. In general, this flag is not set until ->fs_mount() completes successfully, so we know that it is set after the filesystem setup has completed. This matches the trylock_super() behaviour which will not let super_cache_scan() run if SB_BORN is not set, and hence will not allow the superblock shrinker from entering the filesystem while it is being set up or after it has failed setup and is being torn down. Cc: stable@kernel.org Signed-Off-By: Dave Chinner Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman --- fs/super.c | 30 ++++++++++++++++++++++++------ 1 file changed, 24 insertions(+), 6 deletions(-) --- a/fs/super.c +++ b/fs/super.c @@ -120,13 +120,23 @@ static unsigned long super_cache_count(s sb = container_of(shrink, struct super_block, s_shrink); /* - * Don't call trylock_super as it is a potential - * scalability bottleneck. The counts could get updated - * between super_cache_count and super_cache_scan anyway. - * Call to super_cache_count with shrinker_rwsem held - * ensures the safety of call to list_lru_shrink_count() and - * s_op->nr_cached_objects(). + * We don't call trylock_super() here as it is a scalability bottleneck, + * so we're exposed to partial setup state. The shrinker rwsem does not + * protect filesystem operations backing list_lru_shrink_count() or + * s_op->nr_cached_objects(). Counts can change between + * super_cache_count and super_cache_scan, so we really don't need locks + * here. + * + * However, if we are currently mounting the superblock, the underlying + * filesystem might be in a state of partial construction and hence it + * is dangerous to access it. trylock_super() uses a SB_BORN check to + * avoid this situation, so do the same here. The memory barrier is + * matched with the one in mount_fs() as we don't hold locks here. */ + if (!(sb->s_flags & SB_BORN)) + return 0; + smp_rmb(); + if (sb->s_op && sb->s_op->nr_cached_objects) total_objects = sb->s_op->nr_cached_objects(sb, sc); @@ -1226,6 +1236,14 @@ mount_fs(struct file_system_type *type, sb = root->d_sb; BUG_ON(!sb); WARN_ON(!sb->s_bdi); + + /* + * Write barrier is for super_cache_count(). We place it before setting + * SB_BORN as the data dependency between the two functions is the + * superblock structure contents that we just set up, not the SB_BORN + * flag. + */ + smp_wmb(); sb->s_flags |= SB_BORN; error = security_sb_kern_mount(sb, flags, secdata);