Received: by 10.223.185.116 with SMTP id b49csp822678wrg; Sat, 10 Feb 2018 21:12:52 -0800 (PST) X-Google-Smtp-Source: AH8x227btYYB+KLUAzqxVYvVsX5Irb0zXCALl0aiKLUSs3WiOHkV9+EJKjUZy3bqZk5o4a+GpEM/ X-Received: by 2002:a17:902:28c4:: with SMTP id f62-v6mr7175010plb.31.1518325972888; Sat, 10 Feb 2018 21:12:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518325972; cv=none; d=google.com; s=arc-20160816; b=BPnb8+kVHLGATFgYttjkcsuANxgIL0e753Uo/s5oopNaPG7+1R40aD667R7hVzSwVN 8rgwBYDuFPNtb9ojpuX7pw/pjfmJrEf36rOdtBqlqgw7iqzxc12fFPsYxcUUdjJ3XHPy MIXB/L89+GzJCKrHUMsWxQx9hWMwOyT86zjr3DXQVPNoCFkn7UfP+iBDKZ915jb53zDq QQ9xNowOlVH5QQdtQcr8rM6mYZJ0S8643oYj8vcyw4te1FJhHOy5f2PDIuHfm5zgXDyp 6kFdUOBg953cQXSM6EX+D+8uvbCkOksG3LDoOOCDfU7vLgwn5pm6A4VMOkZ32taYgWtZ Qe1w== 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 :arc-authentication-results; bh=WYR3sZWkiU/WtXSbB8unXgtvq6De49Ag6H4pzTxg/4o=; b=ZuQs9buTVxzvZ1s5ZIeaAc9V0o4tQVBNGlLY6IkYEJA4cT8PobFzcokPwdDKxCt/N3 xO1NhVrqUV4/Aj9etBoTt2CC5WaUQQh2BCnlzEokzokMBla38j/l8M3urpTkL7QAjHia YGcqRsf1xCm2Hwa3XAJEkwypKos1Ojhm5o8QHzVbCiU9nsy1O1gRNOtoUxPccMcgdkYx Hxy9ANBMsU243z04cKOT1YkZTBASg0NvpnGZCYRPiVHSAJBE4PESkz+5K/E3pxAR3rLz QXVVQUmMxLZYko2+KiPUALkMKG3szIpQt3Bof73JUkTT8eEQJbxi+LZO3rctyENp/2U4 vVvw== 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 u18si1940086pge.232.2018.02.10.21.12.39; Sat, 10 Feb 2018 21:12:52 -0800 (PST) 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 S1753285AbeBKFME (ORCPT + 99 others); Sun, 11 Feb 2018 00:12:04 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:41409 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752624AbeBKEdm (ORCPT ); Sat, 10 Feb 2018 23:33:42 -0500 Received: from [2a02:8011:400e:2:6f00:88c8:c921:d332] (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 1ekjKc-0002hM-LC; Sun, 11 Feb 2018 04:33:38 +0000 Received: from ben by deadeye with local (Exim 4.90) (envelope-from ) id 1ekjKX-0004SO-9H; Sun, 11 Feb 2018 04:33:33 +0000 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, "Latchesar Ionkov" , "Tuomas Tynkkynen" , "Al Viro" Date: Sun, 11 Feb 2018 04:20:06 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.2 12/79] fs/9p: Compare qid.path in v9fs_test_inode In-Reply-To: X-SA-Exim-Connect-IP: 2a02:8011:400e:2:6f00:88c8:c921:d332 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.2.99-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Tuomas Tynkkynen commit 8ee031631546cf2f7859cc69593bd60bbdd70b46 upstream. Commit fd2421f54423 ("fs/9p: When doing inode lookup compare qid details and inode mode bits.") transformed v9fs_qid_iget() to use iget5_locked() instead of iget_locked(). However, the test() callback is not checking fid.path at all, which means that a lookup in the inode cache can now accidentally locate a completely wrong inode from the same inode hash bucket if the other fields (qid.type and qid.version) match. Fixes: fd2421f54423 ("fs/9p: When doing inode lookup compare qid details and inode mode bits.") Reviewed-by: Latchesar Ionkov Signed-off-by: Tuomas Tynkkynen Signed-off-by: Al Viro Signed-off-by: Ben Hutchings --- fs/9p/vfs_inode.c | 3 +++ fs/9p/vfs_inode_dotl.c | 3 +++ 2 files changed, 6 insertions(+) --- a/fs/9p/vfs_inode.c +++ b/fs/9p/vfs_inode.c @@ -469,6 +469,9 @@ static int v9fs_test_inode(struct inode if (v9inode->qid.type != st->qid.type) return 0; + + if (v9inode->qid.path != st->qid.path) + return 0; return 1; } --- a/fs/9p/vfs_inode_dotl.c +++ b/fs/9p/vfs_inode_dotl.c @@ -105,6 +105,9 @@ static int v9fs_test_inode_dotl(struct i if (v9inode->qid.type != st->qid.type) return 0; + + if (v9inode->qid.path != st->qid.path) + return 0; return 1; }