Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2010859imm; Tue, 10 Jul 2018 11:33:08 -0700 (PDT) X-Google-Smtp-Source: AAOMgpd2o5qml68XFOO/YJ7jCaRhjJHKLd8xIgLvrTuejoDhB0dvWZuWFvr2PDt1WbqnoqwL0iqQ X-Received: by 2002:a63:5055:: with SMTP id q21-v6mr18460170pgl.397.1531247588157; Tue, 10 Jul 2018 11:33:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531247588; cv=none; d=google.com; s=arc-20160816; b=ZRfR10ahxy11LEsZRlUxy+gkmymzuI4mYmsrjPBMQNTa0KYrXjwSGGwUlIFFRta/V3 L/Sbv+V7PxrfsqZF8Zih/aB+vnxe2C6XxEorBDuyUbAJhND0CjZ8RZ0W+DMFrNMHe5Iq 0A0Na00klspWOPm/wl2QFTFXxx0E51OnoGphwb+EpLm8wZA0HBcD87wj/RturOBmVCEI ojtw9FrSWOvE30qmsJ1ClcGff9U7oKdJlzrvvf9MQIgY2PgzrGWb3vzxNA+tkHdthdq2 eU3kD1LuDF15581VQX4HbUWsamULy0xm736xtx5I5+YfbNtk/HvjfVo1BAF0Mi/GMAmY u/kA== 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 :arc-authentication-results; bh=wkUPifYmuMllsiUc2mKOJao/m+pD7HAWxdKkYQKILgE=; b=d3Q0R/d4C9zWNF8X7v5hFEerRbOXH7X4b0vMNg7sSiKtLJ5Nz+NObd0RGiVz42FXg2 ngbSqAwvKB+MzPv5emg2LKELbCtKTx8ZxurwUq4DR4DGfeGwkvMIDogXTi09OvfJEqBf KWB62q6mUIZalzeA8paPq4E58j69IqYm8Y9XE9WelvqzHiECyrnf4pEu156ePHhqneNK FM/1yV00c/5CL+Zh/yZSI5eK7xjYprDffRQ8swJCWR1wHCD5Ul2My/KW+d89yyafkhsq AMpz22PkApneY3K4RR/qnGjnQSd4k2J7o7taqRBlBCl6wtitQ+F3Gkx/vM3eXFlm6yWJ Dqlw== ARC-Authentication-Results: i=1; mx.google.com; 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 j19-v6si2469173pgg.313.2018.07.10.11.32.53; Tue, 10 Jul 2018 11:33:08 -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; 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 S2388489AbeGJSb4 (ORCPT + 99 others); Tue, 10 Jul 2018 14:31:56 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:46528 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732845AbeGJSbz (ORCPT ); Tue, 10 Jul 2018 14:31:55 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 1C96EEE2; Tue, 10 Jul 2018 18:31:42 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Theodore Tso , stable@kernel.org Subject: [PATCH 4.9 32/52] ext4: clear i_data in ext4_inode_info when removing inline data Date: Tue, 10 Jul 2018 20:25:00 +0200 Message-Id: <20180710182452.340146012@linuxfoundation.org> X-Mailer: git-send-email 2.18.0 In-Reply-To: <20180710182449.285532226@linuxfoundation.org> References: <20180710182449.285532226@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.9-stable review patch. If anyone has any objections, please let me know. ------------------ From: Theodore Ts'o commit 6e8ab72a812396996035a37e5ca4b3b99b5d214b upstream. When converting from an inode from storing the data in-line to a data block, ext4_destroy_inline_data_nolock() was only clearing the on-disk copy of the i_blocks[] array. It was not clearing copy of the i_blocks[] in ext4_inode_info, in i_data[], which is the copy actually used by ext4_map_blocks(). This didn't matter much if we are using extents, since the extents header would be invalid and thus the extents could would re-initialize the extents tree. But if we are using indirect blocks, the previous contents of the i_blocks array will be treated as block numbers, with potentially catastrophic results to the file system integrity and/or user data. This gets worse if the file system is using a 1k block size and s_first_data is zero, but even without this, the file system can get quite badly corrupted. This addresses CVE-2018-10881. https://bugzilla.kernel.org/show_bug.cgi?id=200015 Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman --- fs/ext4/inline.c | 1 + 1 file changed, 1 insertion(+) --- a/fs/ext4/inline.c +++ b/fs/ext4/inline.c @@ -434,6 +434,7 @@ static int ext4_destroy_inline_data_nolo memset((void *)ext4_raw_inode(&is.iloc)->i_block, 0, EXT4_MIN_INLINE_DATA_SIZE); + memset(ei->i_data, 0, EXT4_MIN_INLINE_DATA_SIZE); if (ext4_has_feature_extents(inode->i_sb)) { if (S_ISDIR(inode->i_mode) ||