Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp27806imm; Fri, 21 Sep 2018 17:22:43 -0700 (PDT) X-Google-Smtp-Source: ANB0VdbxYLOm3beHTUyI7qf9mxEhS2MHoy5irBvUGsRCXEXBxCJ/Ruu3Ind0vd8hW7A7YJzJlY5t X-Received: by 2002:a62:c008:: with SMTP id x8-v6mr126639pff.149.1537575763224; Fri, 21 Sep 2018 17:22:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537575763; cv=none; d=google.com; s=arc-20160816; b=XWNNUNqfSPdSRXvTzdoBl6Zu1QR2ve0k4CU6FETOHwKH2xJA7KL5hit5aqkBJEy808 oDc9qy6q7F/SLgs8rGyHz1nzIPTtU1Cbovgylb+48ipyh/VUx8//kYFUG2DyeNh1VukK ZvZTssPwGz1nCIOeNUR1jH8LOuQopxBAgcd7hZP6XT4FaEu1kOfrq/gW3+hBsQBf45de iMa8EJV9aQX5qzGBkCr69VE4O8e2h4GFDMWiNjlO1gy15el1A9nSKTP8hWQ5rZbApLVF KdOj9aW74Y5YvRiOjExBeWoTQPljaPjgW7kHVDIoxNLxflMGzQlqC3cgRsNQX1RWGHUw TGsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=VcNCDDdaL55d2wHEFf42M2WxW2M1WJRTcBWCT1AAXu0=; b=Jxq9bDqpFTm6PKicffW4kItLcazXaX9+/HBqliooT5W/LYQtl996tLlULN6lFUr6UD kuP++K8tHRI9AX8mPtSiTm4RphfydIiMau4snRmhkTcKJtIGpUDIMYkQCFLIzayyUsUP Uo3cDHHMxOvmfrmZtQgOyyYKTZuO+YM0rEnxRBjAz1HO1Qu6R2RO61XtKW8/u4t006y3 36p2WO84OK9Mv28aNmQSy9eh6IdJmZ0H7ZLerE/+LXsS/q8ITNjJbg/CM9Uf2Gu4rJ+h B4yDVWMz0Sb8/YzFE+9R47FcEHPZ1AFZTC7K6Pm7G3Tcev3oTi2SoSankEJ3pDPGSalF BMfQ== 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 188-v6si30086980pfg.154.2018.09.21.17.22.27; Fri, 21 Sep 2018 17:22:43 -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 S2392156AbeIVGMw (ORCPT + 99 others); Sat, 22 Sep 2018 02:12:52 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:44248 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2392013AbeIVGKt (ORCPT ); Sat, 22 Sep 2018 02:10:49 -0400 Received: from [2a02:8011:400e:2:cbab:f00:c93f:614] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1g3Vdy-0008BR-7D; Sat, 22 Sep 2018 01:19:30 +0100 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1g3Vdo-0000sQ-8p; Sat, 22 Sep 2018 01:19:20 +0100 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Theodore Ts'o" Date: Sat, 22 Sep 2018 01:15:42 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 34/63] ext4: clear i_data in ext4_inode_info when removing inline data In-Reply-To: X-SA-Exim-Connect-IP: 2a02:8011:400e:2:cbab:f00:c93f:614 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.58-rc1 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 Signed-off-by: Ben Hutchings --- fs/ext4/inline.c | 1 + 1 file changed, 1 insertion(+) --- a/fs/ext4/inline.c +++ b/fs/ext4/inline.c @@ -438,6 +438,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_INCOMPAT_FEATURE(inode->i_sb, EXT4_FEATURE_INCOMPAT_EXTENTS)) {