Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2079981imu; Wed, 28 Nov 2018 22:01:31 -0800 (PST) X-Google-Smtp-Source: AFSGD/WdZz1HGdpRFdPa4+rFegj5VbNUfgpnULhvHmPcapifyp1R9DbyEioB6KRxS94Dte89tBEC X-Received: by 2002:a63:5d14:: with SMTP id r20mr146690pgb.329.1543471291240; Wed, 28 Nov 2018 22:01:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543471291; cv=none; d=google.com; s=arc-20160816; b=P9GhAbZUUBHdvu5bouvRRS7bRrXmLijgMoSPhkU6DDvMpT3iHLWs+jMyzCxNb5GtIa hKP4fON7zSvWRZ5+PR6EXkXWmELWA4sorMjiM+sG2osYQV2IiWbHBdk3eNtWL9XaTLoj qS3mIr712VO/YSIJOk/rsSsFv6Q823NkYsc64Evn1uFwXDX6gZ8CPS4g6mxCiwRahmU8 pcwg49VxyS5ZA8mT38PpYt4zo9UW1AnctSGUjZBRVGI1O+ZMvFVAPzx5frYOhco9BskE uIkQZEtkVlAMW6u/pT4QGA7B6rPmaBm/AuX8vfPcm5n3/Mz7T/lCYnWkDKhirAfv9vv5 Sphw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature; bh=ke0PEUQj00F7Co9n2kigvHGRnQbRazsrkVXhS6Mptv8=; b=GV5lcQ3u5Nmu/98Jf/f/JJ9CJdGigZw1TNm0I0OBOJqSeDscQE9JyzEbAhXW2YWSxR 16JmhQH2MJ82C4Ke1Tr5Ck4ukOslimqJYSZk7jPkJW64Yn2mBLvJr6+Re0LmFWr+DGdt Vl02VXVXP+P0ONV5cmJhqB4HY3/hnAFC8TZX9y9/pO7FAUHCpavZXqaHczaqbMO0T+jD U8JCB72adrsa9iwNOLYyJ6syxng16kUqswximIax7g5MD2hMzWRAG4GXePHzFlm1avNx MrG17MhWZEep6VRHYL812fafVkw6oTqqpLOR+whoJqxsbF5TDdRFyBDLATrsiSjEK19L Uvdg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Payb8tCM; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d10-v6si1173306pla.207.2018.11.28.22.01.16; Wed, 28 Nov 2018 22:01:31 -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=Payb8tCM; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729084AbeK2RER (ORCPT + 99 others); Thu, 29 Nov 2018 12:04:17 -0500 Received: from mail.kernel.org ([198.145.29.99]:38852 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727570AbeK2REQ (ORCPT ); Thu, 29 Nov 2018 12:04:16 -0500 Received: from sasha-vm.mshome.net (unknown [37.142.5.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3A9C421104; Thu, 29 Nov 2018 06:00:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1543471205; bh=WdKGbFxZM9VvN1QzJOdBk7mXBsibUXd5Ruvhu4fCo+c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Payb8tCMypKN8BcfrMPElDbcA0viFKGWJobXaEOYQdxTrWYaGIISKUG/XHGhY9YXP fntTRGcAnHurLwFA3GGWCxN0lgoxPpWlrp1qLePB2oY+7W3uExvNKgWAclYRl0jH7j mFeqiCjwkJMRI3/TmhJTsCApiMVZSxM3/bU1qtAY= From: Sasha Levin To: stable@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Dave Chinner , "Darrick J . Wong" , Sasha Levin , linux-fsdevel@vger.kernel.org Subject: [PATCH AUTOSEL 4.19 52/68] iomap: sub-block dio needs to zeroout beyond EOF Date: Thu, 29 Nov 2018 00:55:43 -0500 Message-Id: <20181129055559.159228-52-sashal@kernel.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20181129055559.159228-1-sashal@kernel.org> References: <20181129055559.159228-1-sashal@kernel.org> 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 fa46e3ed8f53..82e35265679d 100644 --- a/fs/iomap.c +++ b/fs/iomap.c @@ -1678,7 +1678,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.17.1