Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2580327imm; Thu, 16 Aug 2018 11:51:50 -0700 (PDT) X-Google-Smtp-Source: AA+uWPwchQ7lVgXWp0Y3i465wOGUOMFue2NwkS0qMvfRC+Sh2XMitUdMSdVTY7fRZ/Ui1BryZXLU X-Received: by 2002:a62:b40c:: with SMTP id h12-v6mr33667612pfn.18.1534445510320; Thu, 16 Aug 2018 11:51:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534445510; cv=none; d=google.com; s=arc-20160816; b=zdeJ2E5uIaGOyiuvOoqopenDnBPY+XA9IWtFdpzquC9ajgVsekQqwAFa4Wd6Vsh4Ie n686eeHOtxHSDBCYYAuKuMLoaA8AaSWQe4XpSvkZchVRN4fEQ/FHu5VjxOXdZ7RbULKM EQSvgdzLyfvlIdHpW+3pVNbaFU7hxdokFQb8fCY49tQgoLoUcST64ExHq47x9uITnhcs uRKBx+t0rHlk5MwZ46CSqczyBiV2GQuIXvsRVC5ErnCL8112zv6fl6ZEKS1R/xCGJX01 pOrj+FoYeRaL06esrHEkgLTDsoVDru2BViF0qfEJO3n0JoDW5q3V4V+Cs0Qo+fpwcnSc k7XQ== 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 :arc-authentication-results; bh=aNgFaeI3xgcOGWecRUbEzPEzyG4mOPDZ4Qdn37zhzDc=; b=D8dz/piGzwmLY7prvtO9VEqF01h6OopegPdKiAvnP56Nh9jyf6L1qb0S8cJnS4ZiDh i+AHmOjFdM+2BgTSp/ocRCHcunlIkFyHxLXvFYNZHBlohtxP2PYid0iMGwYN2nI2zPZd LM70bIvAHhAqXTKPDrW7yCjjsXeY9yE1rfbsbCpu/lIA6c+O3qJYP8OhoFm86D5lp4Im Jfissx1/5X+2/j1vah3+0/E0QTgkQFUdX8s3OUHWPSW0+gTuDx2uBBpspNfCcjgVX8j1 RLuRBobnQ5C9y0RS9W1BIxusYbc+aheFM+NAVFcMay8cUz05Gd+jSgMCRFCZOHcyq8E4 L69w== 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 x25-v6si44251pfi.138.2018.08.16.11.51.35; Thu, 16 Aug 2018 11:51:50 -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 S1728510AbeHPVmk (ORCPT + 99 others); Thu, 16 Aug 2018 17:42:40 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:56102 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728344AbeHPVmj (ORCPT ); Thu, 16 Aug 2018 17:42:39 -0400 Received: from localhost (unknown [194.244.16.108]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 42AF4CC4; Thu, 16 Aug 2018 18:42:30 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jann Horn , Al Viro Subject: [PATCH 3.18 03/15] fix mntput/mntput race Date: Thu, 16 Aug 2018 20:41:40 +0200 Message-Id: <20180816171633.673294381@linuxfoundation.org> X-Mailer: git-send-email 2.18.0 In-Reply-To: <20180816171633.546734046@linuxfoundation.org> References: <20180816171633.546734046@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 3.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Al Viro commit 9ea0a46ca2c318fcc449c1e6b62a7230a17888f1 upstream. mntput_no_expire() does the calculation of total refcount under mount_lock; unfortunately, the decrement (as well as all increments) are done outside of it, leading to false positives in the "are we dropping the last reference" test. Consider the following situation: * mnt is a lazy-umounted mount, kept alive by two opened files. One of those files gets closed. Total refcount of mnt is 2. On CPU 42 mntput(mnt) (called from __fput()) drops one reference, decrementing component * After it has looked at component #0, the process on CPU 0 does mntget(), incrementing component #0, gets preempted and gets to run again - on CPU 69. There it does mntput(), which drops the reference (component #69) and proceeds to spin on mount_lock. * On CPU 42 our first mntput() finishes counting. It observes the decrement of component #69, but not the increment of component #0. As the result, the total it gets is not 1 as it should've been - it's 0. At which point we decide that vfsmount needs to be killed and proceed to free it and shut the filesystem down. However, there's still another opened file on that filesystem, with reference to (now freed) vfsmount, etc. and we are screwed. It's not a wide race, but it can be reproduced with artificial slowdown of the mnt_get_count() loop, and it should be easier to hit on SMP KVM setups. Fix consists of moving the refcount decrement under mount_lock; the tricky part is that we want (and can) keep the fast case (i.e. mount that still has non-NULL ->mnt_ns) entirely out of mount_lock. All places that zero mnt->mnt_ns are dropping some reference to mnt and they call synchronize_rcu() before that mntput(). IOW, if mntput() observes (under rcu_read_lock()) a non-NULL ->mnt_ns, it is guaranteed that there is another reference yet to be dropped. Reported-by: Jann Horn Tested-by: Jann Horn Fixes: 48a066e72d97 ("RCU'd vsfmounts") Cc: stable@vger.kernel.org Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman --- fs/namespace.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) --- a/fs/namespace.c +++ b/fs/namespace.c @@ -1049,12 +1049,22 @@ static DECLARE_DELAYED_WORK(delayed_mntp static void mntput_no_expire(struct mount *mnt) { rcu_read_lock(); - mnt_add_count(mnt, -1); - if (likely(mnt->mnt_ns)) { /* shouldn't be the last one */ + if (likely(READ_ONCE(mnt->mnt_ns))) { + /* + * Since we don't do lock_mount_hash() here, + * ->mnt_ns can change under us. However, if it's + * non-NULL, then there's a reference that won't + * be dropped until after an RCU delay done after + * turning ->mnt_ns NULL. So if we observe it + * non-NULL under rcu_read_lock(), the reference + * we are dropping is not the final one. + */ + mnt_add_count(mnt, -1); rcu_read_unlock(); return; } lock_mount_hash(); + mnt_add_count(mnt, -1); if (mnt_get_count(mnt)) { rcu_read_unlock(); unlock_mount_hash();