From patchwork Thu Aug 29 14:33:41 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Connor Kuehl X-Patchwork-Id: 1155288 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=canonical.com Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 46K4qt17lFz9sNF; Fri, 30 Aug 2019 00:34:18 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1i3LV8-0000R8-Do; Thu, 29 Aug 2019 14:34:14 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by huckleberry.canonical.com with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.86_2) (envelope-from ) id 1i3LV6-0000Qs-Jd for kernel-team@lists.ubuntu.com; Thu, 29 Aug 2019 14:34:12 +0000 Received: from mail-pl1-f200.google.com ([209.85.214.200]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1i3LV6-0006DO-5M for kernel-team@lists.ubuntu.com; Thu, 29 Aug 2019 14:34:12 +0000 Received: by mail-pl1-f200.google.com with SMTP id t10so2086535plr.9 for ; Thu, 29 Aug 2019 07:34:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=0R9zVhzpeBcKa8KcZm8JzJrqlt4UOH5tSUwxMPXFKio=; b=shhXbHVhDmyJRuzbREjfrwU2cjEGsFixFZ6dYR9ULks8vuklGoVZC87cKjd28HKIst drwF2m+j7jTNH8NdIn17IFNK6P+SQc0He3rMjAt+nufmG4REBPdjeSfRg1TXQvvPQpWl ZaasMwA9i94mMDHapeaCRJNGw2V7CiNc/hYAZj4VVIRE9/lAmYBwBEcPCfFf0gK5c9WA jRSG9sfQeAnvXBhqOaw8CSDP6lB9BJo3Dtmb4slZlJHLYmBkoy70b+gFmd4qZPLQ6B/4 cE1RVy3HNSPFPkFOUJElYfAQ/7rcqPOaf7znDoWmuy5VRIaX326Mgp0tf9K6CZ0NzjED yvog== X-Gm-Message-State: APjAAAVNpvRiYw4DPVIuweL4q5nGSYhXABJUUInJzSjrcI4sAV/4ndIe 0w8d5rKvrGp56peUeLv+7WVokkwHGtoOSqU3XKeuxw3miTpF0yL05Xnz5fBPktm9Q4kDy4IBZva ydpinkxBetdKfydoCYx9rKjfk6IWkW9prhky95B7KKQ== X-Received: by 2002:a63:6206:: with SMTP id w6mr8578633pgb.428.1567089250267; Thu, 29 Aug 2019 07:34:10 -0700 (PDT) X-Google-Smtp-Source: APXvYqySnFkRKJzJZx1twuEH/MePqndoBTZyzcLp+E9n5symiuTWvs0xppFLVStPYkekSxmYERiLOg== X-Received: by 2002:a63:6206:: with SMTP id w6mr8578603pgb.428.1567089249978; Thu, 29 Aug 2019 07:34:09 -0700 (PDT) Received: from localhost.localdomain (c-24-20-45-88.hsd1.or.comcast.net. [24.20.45.88]) by smtp.gmail.com with ESMTPSA id g11sm2744979pgu.11.2019.08.29.07.34.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Aug 2019 07:34:09 -0700 (PDT) From: Connor Kuehl To: kernel-team@lists.ubuntu.com Subject: [X/B][SRU][CVE-2018-20976][PATCH] xfs: clear sb->s_fs_info on mount failure Date: Thu, 29 Aug 2019 07:33:41 -0700 Message-Id: <20190829143341.13920-1-connor.kuehl@canonical.com> X-Mailer: git-send-email 2.17.1 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Dave Chinner CVE-2018-20976 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. Essentially, the machine was under memory pressure when the mount was being run, xfs_fs_fill_super() failed after allocating the xfs_mount and attaching it to sb->s_fs_info. It then cleaned up and freed the xfs_mount, but the sb->s_fs_info field still pointed to the freed memory. Hence when the superblock shrinker then ran it fell off the bad pointer. With the superblock shrinker problem fixed at teh VFS level, this stale s_fs_info pointer is still a problem - we use it unconditionally in ->put_super when the superblock is being torn down, and hence we can still trip over it after a ->fill_super call failure. Hence we need to clear s_fs_info if xfs-fs_fill_super() fails, and we need to check if it's valid in the places it can potentially be dereferenced after a ->fill_super failure. Signed-Off-By: Dave Chinner Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong (cherry picked from commit c9fbd7bbc23dbdd73364be4d045e5d3612cf6e82) Signed-off-by: Connor Kuehl Acked-by: Kleber Sacilotto de Souza --- fs/xfs/xfs_super.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index ef64a1e1a66a..ff3f5812c0fd 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -1572,6 +1572,7 @@ xfs_fs_fill_super( out_close_devices: xfs_close_devices(mp); out_free_fsname: + sb->s_fs_info = NULL; xfs_free_fsname(mp); kfree(mp); out: @@ -1589,6 +1590,10 @@ xfs_fs_put_super( { struct xfs_mount *mp = XFS_M(sb); + /* if ->fill_super failed, we have no mount to tear down */ + if (!sb->s_fs_info) + return; + xfs_notice(mp, "Unmounting Filesystem"); xfs_filestream_unmount(mp); xfs_unmountfs(mp); @@ -1598,6 +1603,8 @@ xfs_fs_put_super( xfs_destroy_percpu_counters(mp); xfs_destroy_mount_workqueues(mp); xfs_close_devices(mp); + + sb->s_fs_info = NULL; xfs_free_fsname(mp); kfree(mp); } @@ -1617,6 +1624,9 @@ xfs_fs_nr_cached_objects( struct super_block *sb, struct shrink_control *sc) { + /* Paranoia: catch incorrect calls during mount setup or teardown */ + if (WARN_ON_ONCE(!sb->s_fs_info)) + return 0; return xfs_reclaim_inodes_count(XFS_M(sb)); }