Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp858074ybt; Fri, 19 Jun 2020 16:02:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyKcOQi4ci6dDi27qf+FqYunFCNbfUXBnKF5Gooi0OPOhTu5mBGFeDQpjkkZJgiPjjOevf3 X-Received: by 2002:a17:907:20cf:: with SMTP id qq15mr5618845ejb.238.1592607757545; Fri, 19 Jun 2020 16:02:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592607757; cv=none; d=google.com; s=arc-20160816; b=Ugy6NtqRlQ9U+sOMXqf+1FTaBymTQteVm2rDm+0deEHQJU7TAzDxA7RZGE9yc+o5j5 mw/jS05kxyyyuyHiyC4AEqm0fmOdBRZIuOUUxpQD7DF12j+RfcSDhW08N/EBFZAGhhV9 Ds6866090FS7JBSrvMCGiJjhkx6ks4fnG0GJH9Uq5LxSI67juURBmY81HadX6gu9YVSa k4mopi/4J0ZDBlT8ik3hwisIzbtoOB6vT1GNSi91yuUF7qmooy0/a1/4MtFwctYWwm9q zaFrcC7yPK2YPxeGrc55g8QAbLlfIG7FYI2A7AzFM1Hy0Rs+YoGWfcFAHOYGTj59xvNo 1zvA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=cWoXZRqu3eG/qx+lcOxSuhfrgWV2qdtGXb/oiL2C1L8=; b=b7gKoK4zwUWBRwcO7zo/l9tWRZR98qu/RSMOsNfC9yUhl8rfL8qaDg5EvQChEj1DcQ CdDjV4VPJcCSNnZeYy0j9BA7kVxCY3kAKmRAgfMlphdCflIfHj2utAi4pIH/CnbKbBFT H1NY44E+WWNKy9x5nrajYTeh1HDDwYndfqt1LxObAMCTpe2rSnflMAEGZ8nhdtNZVCdg BkwMQ1vIdu+NLPiDXqc/VjCMPl31jYjeXrwLs+QLsU7lXAYU4T7Vsp3lwT91UPxAdSvN 0+SKeB3zfaSVT4L7yY8Oi8UtSY/6lXc+rMAQ0LWjlEpU4v+pjq32Gp3OM+ecyaEUy2CF vgPw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="T/M4uGwE"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l3si5412961edi.536.2020.06.19.16.02.15; Fri, 19 Jun 2020 16:02:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="T/M4uGwE"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390143AbgFSPaL (ORCPT + 99 others); Fri, 19 Jun 2020 11:30:11 -0400 Received: from mail.kernel.org ([198.145.29.99]:33856 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404408AbgFSPaH (ORCPT ); Fri, 19 Jun 2020 11:30:07 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 87CC121D79; Fri, 19 Jun 2020 15:30:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592580606; bh=biZxo7xIfF834z9nqNS71nzofZ7r6Uqho9xZzSIhqPU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=T/M4uGwE4cFSiLPvH4M0BCwwOH0UDMR2e7KdhdMgxQda9UrkWO+baqRn7ue9+jVVs 3VdL20tpM5PQTGi89gLUpbY0UWJ+5nnlrJ6m03a0uHVrtqrJCLXa2+xHjlr+/02sIS sorhIKrMGn9SaXdscFTSIbsflBqIf3bU3P9BX+9A= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Eric Biggers , Theodore Tso Subject: [PATCH 5.7 283/376] ext4: fix race between ext4_sync_parent() and rename() Date: Fri, 19 Jun 2020 16:33:21 +0200 Message-Id: <20200619141723.728742706@linuxfoundation.org> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20200619141710.350494719@linuxfoundation.org> References: <20200619141710.350494719@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Eric Biggers commit 08adf452e628b0e2ce9a01048cfbec52353703d7 upstream. 'igrab(d_inode(dentry->d_parent))' without holding dentry->d_lock is broken because without d_lock, d_parent can be concurrently changed due to a rename(). Then if the old directory is immediately deleted, old d_parent->inode can be NULL. That causes a NULL dereference in igrab(). To fix this, use dget_parent() to safely grab a reference to the parent dentry, which pins the inode. This also eliminates the need to use d_find_any_alias() other than for the initial inode, as we no longer throw away the dentry at each step. This is an extremely hard race to hit, but it is possible. Adding a udelay() in between the reads of ->d_parent and its ->d_inode makes it reproducible on a no-journal filesystem using the following program: #include #include int main() { if (fork()) { for (;;) { mkdir("dir1", 0700); int fd = open("dir1/file", O_RDWR|O_CREAT|O_SYNC); write(fd, "X", 1); close(fd); } } else { mkdir("dir2", 0700); for (;;) { rename("dir1/file", "dir2/file"); rmdir("dir1"); } } } Fixes: d59729f4e794 ("ext4: fix races in ext4_sync_parent()") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Link: https://lore.kernel.org/r/20200506183140.541194-1-ebiggers@kernel.org Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman --- fs/ext4/fsync.c | 28 +++++++++++++--------------- 1 file changed, 13 insertions(+), 15 deletions(-) --- a/fs/ext4/fsync.c +++ b/fs/ext4/fsync.c @@ -44,30 +44,28 @@ */ static int ext4_sync_parent(struct inode *inode) { - struct dentry *dentry = NULL; - struct inode *next; + struct dentry *dentry, *next; int ret = 0; if (!ext4_test_inode_state(inode, EXT4_STATE_NEWENTRY)) return 0; - inode = igrab(inode); + dentry = d_find_any_alias(inode); + if (!dentry) + return 0; while (ext4_test_inode_state(inode, EXT4_STATE_NEWENTRY)) { ext4_clear_inode_state(inode, EXT4_STATE_NEWENTRY); - dentry = d_find_any_alias(inode); - if (!dentry) - break; - next = igrab(d_inode(dentry->d_parent)); + + next = dget_parent(dentry); dput(dentry); - if (!next) - break; - iput(inode); - inode = next; + dentry = next; + inode = dentry->d_inode; + /* * The directory inode may have gone through rmdir by now. But * the inode itself and its blocks are still allocated (we hold - * a reference to the inode so it didn't go through - * ext4_evict_inode()) and so we are safe to flush metadata - * blocks and the inode. + * a reference to the inode via its dentry), so it didn't go + * through ext4_evict_inode()) and so we are safe to flush + * metadata blocks and the inode. */ ret = sync_mapping_buffers(inode->i_mapping); if (ret) @@ -76,7 +74,7 @@ static int ext4_sync_parent(struct inode if (ret) break; } - iput(inode); + dput(dentry); return ret; }