From patchwork Tue Sep 29 10:59:48 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 262867 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=-13.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, USER_AGENT_GIT autolearn=unavailable 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 73A8CC47423 for ; Tue, 29 Sep 2020 12:48:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 29EF920C09 for ; Tue, 29 Sep 2020 12:48:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1601383708; bh=mHHxkIzXOTC2isNxEZdMuSwlzOD4/OnX+lG+fgZxp8o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=eObrOvOuXxREMEbjuCEVNt+Qx2Cjb6DP0DfrulEwiJR8/XLEmDUYvkmP5am5CtOJz 6L2OdFtUWqnMiu2vRKFbZetG//eT+5EeC0aLOL8okqfd77t93sn4HIAN6xJdEQ7EFA nPjHvcpBgQbZf3zSt7PqJDTeQntgslYT3tl+Hgrk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728394AbgI2LDU (ORCPT ); Tue, 29 Sep 2020 07:03:20 -0400 Received: from mail.kernel.org ([198.145.29.99]:38968 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728337AbgI2LDT (ORCPT ); Tue, 29 Sep 2020 07:03:19 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (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 EEE6321D41; Tue, 29 Sep 2020 11:03:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1601377398; bh=mHHxkIzXOTC2isNxEZdMuSwlzOD4/OnX+lG+fgZxp8o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=E5GCIY+cfmIBmKTATqSAE1kGQiMjl/WunQFtLMUaP3RBWgTRzHDokmSg++biYc+Sx oQUbjQ/+PRl6FCEEQHtg8eVPDy/85apTSul7gzGD902umulK6xIK7F3yurYZ6CVoUl ykU2nbtsGrKf6k/9ighw37Rab9ZpFHW7+m2iVoYA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Brian Foster , "Darrick J. Wong" , Sasha Levin Subject: [PATCH 4.4 21/85] xfs: fix attr leaf header freemap.size underflow Date: Tue, 29 Sep 2020 12:59:48 +0200 Message-Id: <20200929105929.284644336@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200929105928.198942536@linuxfoundation.org> References: <20200929105928.198942536@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Brian Foster [ Upstream commit 2a2b5932db67586bacc560cc065d62faece5b996 ] The leaf format xattr addition helper xfs_attr3_leaf_add_work() adjusts the block freemap in a couple places. The first update drops the size of the freemap that the caller had already selected to place the xattr name/value data. Before the function returns, it also checks whether the entries array has encroached on a freemap range by virtue of the new entry addition. This is necessary because the entries array grows from the start of the block (but end of the block header) towards the end of the block while the name/value data grows from the end of the block in the opposite direction. If the associated freemap is already empty, however, size is zero and the subtraction underflows the field and causes corruption. This is reproduced rarely by generic/070. The observed behavior is that a smaller sized freemap is aligned to the end of the entries list, several subsequent xattr additions land in larger freemaps and the entries list expands into the smaller freemap until it is fully consumed and then underflows. Note that it is not otherwise a corruption for the entries array to consume an empty freemap because the nameval list (i.e. the firstused pointer in the xattr header) starts beyond the end of the corrupted freemap. Update the freemap size modification to account for the fact that the freemap entry can be empty and thus stale. Signed-off-by: Brian Foster Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin --- fs/xfs/libxfs/xfs_attr_leaf.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/xfs/libxfs/xfs_attr_leaf.c b/fs/xfs/libxfs/xfs_attr_leaf.c index da8747b870df3..4539ff4d351f9 100644 --- a/fs/xfs/libxfs/xfs_attr_leaf.c +++ b/fs/xfs/libxfs/xfs_attr_leaf.c @@ -1326,7 +1326,9 @@ xfs_attr3_leaf_add_work( for (i = 0; i < XFS_ATTR_LEAF_MAPSIZE; i++) { if (ichdr->freemap[i].base == tmp) { ichdr->freemap[i].base += sizeof(xfs_attr_leaf_entry_t); - ichdr->freemap[i].size -= sizeof(xfs_attr_leaf_entry_t); + ichdr->freemap[i].size -= + min_t(uint16_t, ichdr->freemap[i].size, + sizeof(xfs_attr_leaf_entry_t)); } } ichdr->usedbytes += xfs_attr_leaf_entsize(leaf, args->index);