Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2082343imu; Wed, 28 Nov 2018 22:04:14 -0800 (PST) X-Google-Smtp-Source: AFSGD/WWgCys/YrHfQN1rMkRbyeKrBF2VmZZKP0OxT9PV77b9lgkXdTAelFkvkhnl2D/c3sC2SgH X-Received: by 2002:a17:902:b01:: with SMTP id 1mr184527plq.331.1543471454193; Wed, 28 Nov 2018 22:04:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543471454; cv=none; d=google.com; s=arc-20160816; b=vg7retLjOIGHEHmV9fP9Hh+A87HIqdLRSk/V3tZcl3sctyM0JGMOsaEzvhm2AP2R59 JlHXq2Yx2MCgMXTfvqY2PH2wCvwgXbVr/qJMa6CvFqyv2jiMbqzIx9f2tZQCW34YRBwU Y5okMiqtp5j7nUhajsEfKtrvA4de+eaDezN2VxcVXa/Kjp47HsL60KfiZvxJioZef8Wj CtfRhQA2miByKZhlnjxqTAajse4JJG58z2hkIh9jvho2CV3nd9vlI3t0+BHxiMNbnCqC T3kJPHaEUhrTO86oRh8Q8akD0SaAp2n4zknevq+UHcG3qpeIXqngWkPTz4rzlKEkSjF5 U42w== 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=ic7PEsNTkEKGbcuHP1gXtv5PlT8MLIFiijaeuc+zdPs=; b=yTA3nDEPpLTV+7l9fasAx/QlimNbUpqAeKcxsdjoCvcgeoHrreHDqdAfF5lBknCYz4 ecuveLBRvbiLHSdBuSNqNqfeHp3Y1goMtjvUbd5gGdYTg8x5Yk1IuuqdwoaBi6eVw5ls T7hIfa/F+ApafWK8PCkcLxXpYbErWqCA26ghscQabz2TEfhGxSpXBiX35MNYzc2MHjiL ESfCsBicitBGDg/wZSlNwO6AaC3IWrbSMOMuV+LFcmlPWUcJkkK1nLCGqzmaeKP6UiXo 6xwzPlwhKleyor+0RDHd05RbD9u3V5fEsKu0eh6u2RqdlbYpvTZRLas0dYbCJUZGey5Y PnRg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=EQOo9aky; 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 u2si993085pgo.544.2018.11.28.22.03.59; Wed, 28 Nov 2018 22:04:14 -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=EQOo9aky; 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 S1729771AbeK2RG5 (ORCPT + 99 others); Thu, 29 Nov 2018 12:06:57 -0500 Received: from mail.kernel.org ([198.145.29.99]:43800 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728459AbeK2RG4 (ORCPT ); Thu, 29 Nov 2018 12:06:56 -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 CF04C213A2; Thu, 29 Nov 2018 06:02:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1543471365; bh=Y2DGkWayWdKe5u1caSXSPraCZVXWFyu9URYJEP3L+Lk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EQOo9akyJSzPu06aQHvTLW/GlZtT1V6ObTwR/gCaUioSiodG44WisJf9p1oFGY2Gw 1Vf/Eh8430IFlgxFVq82x7gAYDOrubQJoJqTcHIrvgEg44jK8cPlvXVrHkylvta4w1 +eSLAIeJkraW2HPTc9gDTiPnLyvbsFnauEZ2QXaA= 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.14 25/35] iomap: sub-block dio needs to zeroout beyond EOF Date: Thu, 29 Nov 2018 01:00:59 -0500 Message-Id: <20181129060110.159878-25-sashal@kernel.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20181129060110.159878-1-sashal@kernel.org> References: <20181129060110.159878-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 8f7673a69273..407efdae3978 100644 --- a/fs/iomap.c +++ b/fs/iomap.c @@ -940,7 +940,14 @@ iomap_dio_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