Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2252628imm; Mon, 28 May 2018 04:49:42 -0700 (PDT) X-Google-Smtp-Source: AB8JxZp3y9MfD2m2Oo/ba68Pxd9jO753p0pHeEhJ1TbCDe6VaYeDlJ9YI0k9KwmuUlL1Q3aPIiHW X-Received: by 2002:a17:902:981:: with SMTP id 1-v6mr13311325pln.11.1527508182633; Mon, 28 May 2018 04:49:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527508182; cv=none; d=google.com; s=arc-20160816; b=VC3PStyysBSfwrlbUtc3XL1Jt1LcWPRfqDSQMNsgd2bqgpDDiWXPYb5ib9y6xRMiBx Ahcbi0fIKrGc53vYFsC+x+SkiMq+i0kpQnVAMM6RxRpgXe5W5bV+lEx16A1UslMcpMvP KQsUwbhiphWfqh4HwzdRVlSHM5GYfsqnnOeV8kW0HZEjAlsWZU+zL4t0ldbvz/yK6rcD 6t5O3EF02FrPND+VJKknrIiwNssAuGOrYAuopPPJAEhepgdjjb2wapvhtEhjnLxM6FWu dy5J7x0zoypvVC0ZW7JBW8fO0uJpCAknbOuGkTBf6NKN2gLE9SAynwXhwgfeUTsBxGsI PFiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from:dkim-signature :arc-authentication-results; bh=tmTMtWEIZaUqU2Z2yXeQ2BCoRy/tUd8p82LiASHRFzI=; b=e4JzZkH2Nx2YoAbtWOKg0yaZNYQutebDhUAVkrHUbUMg9xMD13GaQW3WjbXn1rDq2R 6Rr6yQxdmLm/SUEPDYt00yjJb2UAMAMKC+4njQ4E6+T3lXR8ZOJCg+eLw+EFBq6ZrK28 zHsEKDv8SQOtisaKG7LwSyceZ+CKHwMOHwt2XuJcgJuTu0wjOkNKcfdL2+L6oKRUtuUG 8nglm/i49gkXBSHiZZ2I6NAIZuB3e3Lf0qz00YKh+AZRry8c0/VNIJ8TKd8IcERNW+jm BwOaui55EZcZq1qJBbSDwejoU0Ar3G6fR1tmFspJkBWYl88FCtFUbx9rgY46A2B60vKX GV7Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Dcmg4NRM; 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 h185-v6si29425595pfe.332.2018.05.28.04.49.27; Mon, 28 May 2018 04:49:42 -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; dkim=pass header.i=@kernel.org header.s=default header.b=Dcmg4NRM; 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 S1423614AbeE1LKX (ORCPT + 99 others); Mon, 28 May 2018 07:10:23 -0400 Received: from mail.kernel.org ([198.145.29.99]:58278 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1423874AbeE1LKK (ORCPT ); Mon, 28 May 2018 07:10:10 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) (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 DBBAA2087E; Mon, 28 May 2018 11:10:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1527505809; bh=ulB/9Z+3WkJ4jX9AVcPRh2aZf37EBlbDWxqLTzSM/mI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Dcmg4NRMSH52ikAGnXme21MMyvQxkPl0fauhh4qz+SFni8a5JG39SPFAfN+PoF+7r ir+u1b9AhxA6jCWgmqPbAaYx5lE2V09C2MuFqmECkSyLklJvAb5QcCn6F06qWz67rJ A4/0DpFeprtpSc6+XSUSdEJEMwAwwv/FoTF9y/rc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Andreas Gruenbacher , Bob Peterson , Sasha Levin Subject: [PATCH 4.16 136/272] gfs2: Check for the end of metadata in punch_hole Date: Mon, 28 May 2018 12:02:49 +0200 Message-Id: <20180528100252.485338569@linuxfoundation.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180528100240.256525891@linuxfoundation.org> References: <20180528100240.256525891@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.16-stable review patch. If anyone has any objections, please let me know. ------------------ From: Andreas Gruenbacher [ Upstream commit bb491ce67aa7c1635e5ae4f2f304a7d13d3dbe71 ] When punching a hole or truncating an inode down to a given size, also check if the truncate point / start of the hole is within the range we have metadata for. Otherwise, we can end up freeing blocks that shouldn't be freed, corrupting the inode, or crashing the machine when trying to punch a hole into the void. When growing an inode via truncate, we set the new size but we don't allocate additional levels of indirect blocks and grow the inode height. When shrinking that inode again, the new size may still point beyond the end of the inode's metadata. Fixes xfstest generic/476. Debugged-by: Bob Peterson Signed-off-by: Andreas Gruenbacher Signed-off-by: Bob Peterson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- fs/gfs2/bmap.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) --- a/fs/gfs2/bmap.c +++ b/fs/gfs2/bmap.c @@ -1344,6 +1344,7 @@ static inline bool walk_done(struct gfs2 static int punch_hole(struct gfs2_inode *ip, u64 offset, u64 length) { struct gfs2_sbd *sdp = GFS2_SB(&ip->i_inode); + u64 maxsize = sdp->sd_heightsize[ip->i_height]; struct metapath mp = {}; struct buffer_head *dibh, *bh; struct gfs2_holder rd_gh; @@ -1359,6 +1360,14 @@ static int punch_hole(struct gfs2_inode u64 prev_bnr = 0; __be64 *start, *end; + if (offset >= maxsize) { + /* + * The starting point lies beyond the allocated meta-data; + * there are no blocks do deallocate. + */ + return 0; + } + /* * The start position of the hole is defined by lblock, start_list, and * start_aligned. The end position of the hole is defined by lend, @@ -1372,7 +1381,6 @@ static int punch_hole(struct gfs2_inode */ if (length) { - u64 maxsize = sdp->sd_heightsize[ip->i_height]; u64 end_offset = offset + length; u64 lend;