Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp30003imm; Fri, 21 Sep 2018 17:26:15 -0700 (PDT) X-Google-Smtp-Source: ACcGV619zTHgOnQ8EodrA0NlBdWaKEiaYSiiozCCRA6HUR+PZ9gvsK0oZ/2KmFJN/mDZhCITGSa3 X-Received: by 2002:a63:f309:: with SMTP id l9-v6mr104125pgh.369.1537575975325; Fri, 21 Sep 2018 17:26:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537575975; cv=none; d=google.com; s=arc-20160816; b=FX+hy8dIlRclgHbqf+1t7mlzUOon3ayBiOdGJ2P9dSSjCRRJ1RGgAs2TEws164+xkp 0RG5jxGV9fRlpo0Xnm05BGnHy8yLVP7OePmtMwvcAG2Bhkru4Ld09ToVuVgEfK/Avaba CyHcnlwxA9nwHayldRYIcB+ySL0YNUQMb+rXvOpJrWGdJtMVgwq9pfP+cPzCipfUoyUf nt2fIJYzchxH02YlcvyUonWgmLwW7/SVpWswqLXxrRCM+hB6inlaNHbH8EcjBhDSb8Dw aYEbpqhPOyIVoG1A3/DfgkOfukRrkD1Ck7sBtooswV4Z4ixuPcRjwrRzoRW0pUsm1Pm7 frEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=sHHBdKY2lKFyTawdKOL9/MafGzwR6vV0O99Gsuun+fw=; b=bSuSwfae2wiUkTv7mY4J1JKKE10NyV1FKqML9qLclJT+NECCm9wS87HVBixb6HgMQr MYNjV2+yQ99BUjLldcgEkSRxXq+wwfIhVkzNzayIN9mmz5BNwK/RyUAgRLLNE/WpMVaK 44+XX7dzvqxzDtyXUX0L6VMLpir1z4Vjb19yj/A2uhM9PZGA0kls/RbYEdvJGFNbwSIK ez/CCKJlKCeT1JYDPziNAMYqxDZszXGIXfZOC8MgVAz/g97qbxBVopczg06SjjjO7xaj RSBuSW2hqDz+0ke6tUZ7Woud6ScGjZ1QYOlgjWIiqLb3zq/XGunwXLIBW+aXiEccJmPW wqlw== ARC-Authentication-Results: i=1; mx.google.com; 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 k1-v6si27571873pgj.522.2018.09.21.17.25.59; Fri, 21 Sep 2018 17:26:15 -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; 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 S2392041AbeIVGPR (ORCPT + 99 others); Sat, 22 Sep 2018 02:15:17 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:44166 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391936AbeIVGKq (ORCPT ); Sat, 22 Sep 2018 02:10:46 -0400 Received: from [2a02:8011:400e:2:cbab:f00:c93f:614] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1g3Vdv-0008BW-6s; Sat, 22 Sep 2018 01:19:27 +0100 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1g3Vdo-0000ts-Ug; Sat, 22 Sep 2018 01:19:20 +0100 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Dave Chinner" , "Christoph Hellwig" , "Wen Xu" , "Carlos Maiolino" , "Darrick J. Wong" Date: Sat, 22 Sep 2018 01:15:42 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 52/63] xfs: validate cached inodes are free when allocated In-Reply-To: X-SA-Exim-Connect-IP: 2a02:8011:400e:2:cbab:f00:c93f:614 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.58-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Dave Chinner commit afca6c5b2595fc44383919fba740c194b0b76aff upstream. A recent fuzzed filesystem image cached random dcache corruption when the reproducer was run. This often showed up as panics in lookup_slow() on a null inode->i_ops pointer when doing pathwalks. BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 .... Call Trace: lookup_slow+0x44/0x60 walk_component+0x3dd/0x9f0 link_path_walk+0x4a7/0x830 path_lookupat+0xc1/0x470 filename_lookup+0x129/0x270 user_path_at_empty+0x36/0x40 path_listxattr+0x98/0x110 SyS_listxattr+0x13/0x20 do_syscall_64+0xf5/0x280 entry_SYSCALL_64_after_hwframe+0x42/0xb7 but had many different failure modes including deadlocks trying to lock the inode that was just allocated or KASAN reports of use-after-free violations. The cause of the problem was a corrupt INOBT on a v4 fs where the root inode was marked as free in the inobt record. Hence when we allocated an inode, it chose the root inode to allocate, found it in the cache and re-initialised it. We recently fixed a similar inode allocation issue caused by inobt record corruption problem in xfs_iget_cache_miss() in commit ee457001ed6c ("xfs: catch inode allocation state mismatch corruption"). This change adds similar checks to the cache-hit path to catch it, and turns the reproducer into a corruption shutdown situation. Reported-by: Wen Xu Signed-Off-By: Dave Chinner Reviewed-by: Christoph Hellwig Reviewed-by: Carlos Maiolino Reviewed-by: Darrick J. Wong [darrick: fix typos in comment] Signed-off-by: Darrick J. Wong [bwh: Backported to 3.16: - Look up mode in XFS inode, not VFS inode - Use positive error codes, and EIO instead of EFSCORRUPTED] Signed-off-by: Ben Hutchings --- fs/xfs/xfs_icache.c | 73 +++++++++++++++++++++++++++++---------------- 1 file changed, 48 insertions(+), 25 deletions(-) --- a/fs/xfs/xfs_icache.c +++ b/fs/xfs/xfs_icache.c @@ -133,6 +133,46 @@ xfs_inode_free( } /* + * If we are allocating a new inode, then check what was returned is + * actually a free, empty inode. If we are not allocating an inode, + * then check we didn't find a free inode. + * + * Returns: + * 0 if the inode free state matches the lookup context + * ENOENT if the inode is free and we are not allocating + * EFSCORRUPTED if there is any state mismatch at all + */ +static int +xfs_iget_check_free_state( + struct xfs_inode *ip, + int flags) +{ + if (flags & XFS_IGET_CREATE) { + /* should be a free inode */ + if (ip->i_d.di_mode != 0) { + xfs_warn(ip->i_mount, +"Corruption detected! Free inode 0x%llx not marked free! (mode 0x%x)", + ip->i_ino, ip->i_d.di_mode); + return EIO; + } + + if (ip->i_d.di_nblocks != 0) { + xfs_warn(ip->i_mount, +"Corruption detected! Free inode 0x%llx has blocks allocated!", + ip->i_ino); + return EIO; + } + return 0; + } + + /* should be an allocated inode */ + if (ip->i_d.di_mode == 0) + return ENOENT; + + return 0; +} + +/* * Check the validity of the inode we just found it the cache */ static int @@ -181,12 +221,12 @@ xfs_iget_cache_hit( } /* - * If lookup is racing with unlink return an error immediately. + * Check the inode free state is valid. This also detects lookup + * racing with unlinks. */ - if (ip->i_d.di_mode == 0 && !(flags & XFS_IGET_CREATE)) { - error = ENOENT; + error = xfs_iget_check_free_state(ip, flags); + if (error) goto out_error; - } /* * If IRECLAIMABLE is set, we've torn down the VFS inode already. @@ -295,29 +335,12 @@ xfs_iget_cache_miss( /* - * If we are allocating a new inode, then check what was returned is - * actually a free, empty inode. If we are not allocating an inode, - * the check we didn't find a free inode. + * Check the inode free state is valid. This also detects lookup + * racing with unlinks. */ - if (flags & XFS_IGET_CREATE) { - if (ip->i_d.di_mode != 0) { - xfs_warn(mp, -"Corruption detected! Free inode 0x%llx not marked free on disk", - ino); - error = EIO; - goto out_destroy; - } - if (ip->i_d.di_nblocks != 0) { - xfs_warn(mp, -"Corruption detected! Free inode 0x%llx has blocks allocated!", - ino); - error = EIO; - goto out_destroy; - } - } else if (ip->i_d.di_mode == 0) { - error = ENOENT; + error = xfs_iget_check_free_state(ip, flags); + if (error) goto out_destroy; - } /* * Preload the radix tree so we can insert safely under the