Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp777701ybl; Wed, 11 Dec 2019 07:22:34 -0800 (PST) X-Google-Smtp-Source: APXvYqxlA2cZ3icpsBBQfzE39IRe+YgSyhHMTHHK66pRYeE7pU2N0mrBQHVPG6a+DhNql4vZ/pK+ X-Received: by 2002:aca:3cc3:: with SMTP id j186mr3017623oia.169.1576077754517; Wed, 11 Dec 2019 07:22:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576077754; cv=none; d=google.com; s=arc-20160816; b=G803a376fHP/2zVXc8/w2ntcI08wIEveOCoBtPT780SVmTf7go8c0q9mlFRI1k5IDX 47JKtTvb22o+lNMF2QVYDWb1wYg+wR0G9AO+Go+JMSjVPEbDLdHtlPkKP37tpUsaXaqO x+Lmt9vEtpQ6K11bAzaqDXgBFIHa0sAKrLisKbXvUAmUX4w7SYt0y4/6AgcaW5sInmw1 TitNMjIl8AlYRo/Yw6VD+nTutbhuP0ycxgDHdkGNcsk/9uUgTcNoKQFbzGjNGUFtqo54 dxck2mu6pyfj1ZceWO6sD4ig2duf/v0+MvAwSBSn82KOBIkBVFa+SqGW60mPC0e2+WnP x1aQ== 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=juNy5KOs5kFp9yYwhEHpTcLohotd33OF0C1cWSfdS/0=; b=wKXFnTfmvsRU69g2u26wWHVyQDM4yr1SdVDNmOGat8lECkxLQuIQBfjK6vE/VIg4WZ aM43+AsVzdYvewlwyk1V5FhBJp40ir/y+giCQEpPxcOdlSNYzCYplT5WZuTHWVNvvep6 Gsw5mjCBtpILrM8Tr3Z55PtFeSxIuWpzAOy3f+apR25FNMgAi1qzr5sl1CYOs9LtjZ1C M471hihEFJ9R/1tYtNG5VW6m/eNSW4BruIRungahLaItgW1ZnCu+Ovbh5gghdp5Fdn5J vjlbygt13Xn+X/ZL7aMi3ATFVhLkS1280fCEgRlDE161GYf7Ifccku9QGmzC0uT5URLv g46w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="MkrkPx0/"; 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 g126si1353212oib.105.2019.12.11.07.22.21; Wed, 11 Dec 2019 07:22:34 -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; dkim=pass header.i=@kernel.org header.s=default header.b="MkrkPx0/"; 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 S1732235AbfLKPUo (ORCPT + 99 others); Wed, 11 Dec 2019 10:20:44 -0500 Received: from mail.kernel.org ([198.145.29.99]:50164 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731844AbfLKPUk (ORCPT ); Wed, 11 Dec 2019 10:20:40 -0500 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 371C1208C3; Wed, 11 Dec 2019 15:20:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1576077639; bh=iZ9RA23LH/EUbUqk2SUqX136lV5m46+PcJdsvvImH+M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MkrkPx0/5tFluJx0toh3IY2uBqxj66WfJWijKPaEsMewiMwBKS7kor7ZQQ30YVwN5 EU3tvs3569+TQbZkG+34yEOioOTvbEtAn+ekppQJ16nzHS4DSJEVBOPaEe9PReRFWk ZR3HuhNr/sLv+a6hhd2v5sr4N3bOu1faVOWIUH3c= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dave Chinner , Christoph Hellwig , "Darrick J. Wong" , Sasha Levin Subject: [PATCH 4.19 076/243] iomap: sub-block dio needs to zeroout beyond EOF Date: Wed, 11 Dec 2019 16:03:58 +0100 Message-Id: <20191211150344.236508264@linuxfoundation.org> X-Mailer: git-send-email 2.24.1 In-Reply-To: <20191211150339.185439726@linuxfoundation.org> References: <20191211150339.185439726@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: Dave Chinner [ Upstream commit b450672fb66b4a991a5b55ee24209ac7ae7690ce ] If we are doing sub-block dio that extends EOF, we need to zero the unused tail of the block to initialise the data in it it. If we do not zero the tail of the block, then an immediate mmap read of the EOF block will expose stale data beyond EOF to userspace. Found with fsx running sub-block DIO sizes vs MAPREAD/MAPWRITE operations. Fix this by detecting if the end of the DIO write is beyond EOF and zeroing the tail if necessary. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin --- fs/iomap.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/fs/iomap.c b/fs/iomap.c index 914c07c9e0d6f..d3d227682f7d4 100644 --- a/fs/iomap.c +++ b/fs/iomap.c @@ -1700,7 +1700,14 @@ iomap_dio_bio_actor(struct inode *inode, loff_t pos, loff_t length, dio->submit.cookie = submit_bio(bio); } while (nr_pages); - if (need_zeroout) { + /* + * We need to zeroout the tail of a sub-block write if the extent type + * requires zeroing or the write extends beyond EOF. If we don't zero + * the block tail in the latter case, we can expose stale data via mmap + * reads of the EOF block. + */ + if (need_zeroout || + ((dio->flags & IOMAP_DIO_WRITE) && pos >= i_size_read(inode))) { /* zero out from the end of the write to the end of the block */ pad = pos & (fs_block_size - 1); if (pad) -- 2.20.1