From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 308FBC677FC for ; Thu, 11 Oct 2018 15:40:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EC5E021470 for ; Thu, 11 Oct 2018 15:40:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="yGIx0fLt" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EC5E021470 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730292AbeJKXIe (ORCPT ); Thu, 11 Oct 2018 19:08:34 -0400 Received: from mail.kernel.org ([198.145.29.99]:38954 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726647AbeJKXId (ORCPT ); Thu, 11 Oct 2018 19:08:33 -0400 Received: from localhost (ip-213-127-77-176.ip.prioritytelecom.net [213.127.77.176]) (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 BFED72098A; Thu, 11 Oct 2018 15:40:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1539272449; bh=JCFNiB5CN/u3DuebOyVOf9cwPtykLDPxubZxT9H0Klc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=yGIx0fLt3FcgMjW2DODiZZHnfA8tPwLvq5zilekH3eXYdBJWfOoKQbUJIlhliw+zQ RXKIFaKexqzzb60o43/7o9QrwzHuZ9ldWSzY3z4q6WolculT/s0JVCRgXBkkcGWhAW GtYAw/zys23djpHDOnvNLxSc+e7rbyfAQqPvzCA8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Theodore Tso , Ben Hutchings , Greg Hackmann Subject: [PATCH 3.18 114/120] ext4: never move the system.data xattr out of the inode body Date: Thu, 11 Oct 2018 17:34:55 +0200 Message-Id: <20181011152554.511176406@linuxfoundation.org> X-Mailer: git-send-email 2.19.1 In-Reply-To: <20181011152549.500488630@linuxfoundation.org> References: <20181011152549.500488630@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Theodore Ts'o commit 8cdb5240ec5928b20490a2bb34cb87e9a5f40226 upstream. When expanding the extra isize space, we must never move the system.data xattr out of the inode body. For performance reasons, it doesn't make any sense, and the inline data implementation assumes that system.data xattr is never in the external xattr block. This addresses CVE-2018-10880 https://bugzilla.kernel.org/show_bug.cgi?id=200005 Signed-off-by: Theodore Ts'o [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings Signed-off-by: Greg Hackmann Signed-off-by: Greg Kroah-Hartman --- fs/ext4/xattr.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/fs/ext4/xattr.c +++ b/fs/ext4/xattr.c @@ -1391,6 +1391,11 @@ retry: /* Find the entry best suited to be pushed into EA block */ entry = NULL; for (; !IS_LAST_ENTRY(last); last = EXT4_XATTR_NEXT(last)) { + /* never move system.data out of the inode */ + if ((last->e_name_len == 4) && + (last->e_name_index == EXT4_XATTR_INDEX_SYSTEM) && + !memcmp(last->e_name, "data", 4)) + continue; total_size = EXT4_XATTR_SIZE(le32_to_cpu(last->e_value_size)) + EXT4_XATTR_LEN(last->e_name_len);