Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp1187669ybn; Wed, 2 Oct 2019 12:09:10 -0700 (PDT) X-Google-Smtp-Source: APXvYqwlaC9S6d/gsUF11FRKoFKJaLQtkIX5HZq8oHmxgl0ngepL/OrfBN1fnAkQomnW72npXQ2v X-Received: by 2002:a17:906:768f:: with SMTP id o15mr4414514ejm.42.1570043349984; Wed, 02 Oct 2019 12:09:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570043349; cv=none; d=google.com; s=arc-20160816; b=FAQkWy8mUVbn4Ii66gCNDl1C68YEP/8QAQBkYd2umaSVHFBvGkPaGIUnash/E0fFVO C6On5Of9BarE7Z96osftQmZfAp9az4t1l2r6ZFjqJXkreXwf8TQQvf+V1SMeubMdl8mk x31/FGu8b69g/1JfpH56k6KaR5VOcuwify4KBZtUIZGRiQEgz1OmEYy39q20YX2FBhJy UyncAwdeWRzGtqjAqkTZtmcTvQHCuv2BJodEi1661AJGhG2K9MVQmOOnNONBxN70GgVG g3s10Ut35m5cUEYs/g9Tl6BQE6yPLI05MJK85tSfUot/xaQvWPV88LJdCz/xKG/+2+bJ 9/BA== 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=426hD32alAvGDdDx6ZhodVmpuHB18QlWPuEQA5lUpwg=; b=FfXtH1TjiMf9RADDcfy2dlpb6FhUcSun38PlWYxS6z5v+2riaWltUG93VgiQa0/7+A 44O9NBefBK9y9jjSmr6YNiSJveNFr7SsRvIzGJD/zCZZ4ot27zVV0BGF2BtVGOf03Z7z U7d8+peTMY7J60VFLl1Hz+t0ObhmRDqsNH3fz80JMaws3wj8XOtDZ0kI84lZbLiwHeAe MvF/zzSxoY2bWlzaMdlPYkgZB/Wp8sHWlwZ2fFhkFygN4rofULFsZNeTJPWJiWVcQ2Bb /jIBq6hI9HuL6vEr3vEcuowGvnAO8wdUzZR1jfCt6Oc3lj3lKKmZKaK55TXZeGqJHHFP 440w== 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 pj21si16409ejb.64.2019.10.02.12.08.45; Wed, 02 Oct 2019 12:09:09 -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 S1729406AbfJBTIY (ORCPT + 99 others); Wed, 2 Oct 2019 15:08:24 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:35374 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729096AbfJBTIK (ORCPT ); Wed, 2 Oct 2019 15:08:10 -0400 Received: from [192.168.4.242] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iFjyo-000365-N4; Wed, 02 Oct 2019 20:08:06 +0100 Received: from ben by deadeye with local (Exim 4.92.1) (envelope-from ) id 1iFjyn-0003cQ-Tm; Wed, 02 Oct 2019 20:08:05 +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, Denis Kirjanov , "Christoph Hellwig" , "Sahitya Tummala" Date: Wed, 02 Oct 2019 20:06:51 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 32/87] configfs: Fix use-after-free when accessing sd->s_dentry In-Reply-To: X-SA-Exim-Connect-IP: 192.168.4.242 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.75-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Sahitya Tummala commit f6122ed2a4f9c9c1c073ddf6308d1b2ac10e0781 upstream. In the vfs_statx() context, during path lookup, the dentry gets added to sd->s_dentry via configfs_attach_attr(). In the end, vfs_statx() kills the dentry by calling path_put(), which invokes configfs_d_iput(). Ideally, this dentry must be removed from sd->s_dentry but it doesn't if the sd->s_count >= 3. As a result, sd->s_dentry is holding reference to a stale dentry pointer whose memory is already freed up. This results in use-after-free issue, when this stale sd->s_dentry is accessed later in configfs_readdir() path. This issue can be easily reproduced, by running the LTP test case - sh fs_racer_file_list.sh /config (https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/fs/racer/fs_racer_file_list.sh) Fixes: 76ae281f6307 ('configfs: fix race between dentry put and lookup') Signed-off-by: Sahitya Tummala Signed-off-by: Christoph Hellwig Signed-off-by: Ben Hutchings --- fs/configfs/dir.c | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) --- a/fs/configfs/dir.c +++ b/fs/configfs/dir.c @@ -58,15 +58,13 @@ static void configfs_d_iput(struct dentr if (sd) { /* Coordinate with configfs_readdir */ spin_lock(&configfs_dirent_lock); - /* Coordinate with configfs_attach_attr where will increase - * sd->s_count and update sd->s_dentry to new allocated one. - * Only set sd->dentry to null when this dentry is the only - * sd owner. - * If not do so, configfs_d_iput may run just after - * configfs_attach_attr and set sd->s_dentry to null - * even it's still in use. + /* + * Set sd->s_dentry to null only when this dentry is the one + * that is going to be killed. Otherwise configfs_d_iput may + * run just after configfs_attach_attr and set sd->s_dentry to + * NULL even it's still in use. */ - if (atomic_read(&sd->s_count) <= 2) + if (sd->s_dentry == dentry) sd->s_dentry = NULL; spin_unlock(&configfs_dirent_lock);