Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp126180iof; Sun, 5 Jun 2022 23:08:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzuH6Qcer1RS0PiVGdR7Uh7ceJnHpdF+bKdgbTv2HtRfbA1wFefaOL+SncUxvT1yNTvTtMi X-Received: by 2002:a17:90a:66c1:b0:1e8:43ae:f7c0 with SMTP id z1-20020a17090a66c100b001e843aef7c0mr14594244pjl.245.1654495730872; Sun, 05 Jun 2022 23:08:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654495730; cv=none; d=google.com; s=arc-20160816; b=FTa139gwwS8HbRNA61zpH32FPymYH75AYmHG2/rpHyObE++YvOaicNlYLAwG/gKWyZ l8xrz9YhtWjGC12oAVHkIKvcP5GYAfpgMbW6rAIUs6u+1QGT91eB3ZEil7eLe9v5TQtz d/CRBHRlixyBaNQGYacJuLHb344kF+giD+csgX6I7a4D53sycNJ2lQatjkAjuxDxtL7N ErRGDI7JOCMIoKD9f6l7EEXtWCq6dswvdxlxc2KKOce8o4nCaOJt9RdrS1LoiIlq/3PS S/yGqMDpOaVyJFWKAfo2haTZ4oVGtdrfWWZt4R2aJCo59DGBjIzdZcYSRJRsiH6A1GVk 1NUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=eS2SYkvuLJ3WWfu2XQtfzGAVV9PwKzTgC/IOpPeJTeI=; b=ZaDq7ztogiKkoVf6gz0Em4nG4x2sXiLpR+viBadl7ZNTi+F4Lrvije24dlcsX5/H1T q/1GPe5//TLAVYsg3K2hsXb+ruGi1LxtH63kBhzo+e0kgosKA36ACtkTUD0cbgyFsmIB xaCM7fpKl4rWcte+YkcMPnA+VUs2bhc4ReIrQ8K5AbBO/rbznnswmfnWK/2p7lqqPwtO FrpMcZkl2HwHNd4sdw/XWCykbN+iSi+6rSRsFXWOdJkq+CHSyaMRHSA1bEESvXi8ATEh c2+X7PhfbBV3pG6nZ7efoLSajx8Zdh0uv1XpSCbozyYcCGgi5dl60+wGxJcneV97QyN9 OQ9g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=UAtTWNby; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id w7-20020a63a747000000b003fc6682b1ebsi23612616pgo.223.2022.06.05.23.08.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Jun 2022 23:08:50 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=UAtTWNby; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 3D8B916CF5B; Sun, 5 Jun 2022 21:59:28 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241216AbiFCRyA (ORCPT + 99 others); Fri, 3 Jun 2022 13:54:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45970 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345844AbiFCRu3 (ORCPT ); Fri, 3 Jun 2022 13:50:29 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5345B59320; Fri, 3 Jun 2022 10:46:27 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 9E6AD60A24; Fri, 3 Jun 2022 17:46:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 83E8DC385B8; Fri, 3 Jun 2022 17:46:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278386; bh=ckAXMjdtX0ur87WUhgGjR/BsA7WVjQYxbNCalliwZs8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UAtTWNbyZBv//mlVQJbgoqVRxRNv4/0SdOP29eHkssr4j0rfw8Qi7s2dMDWqaKuAA Z0ickdhdI+syb9Bi839L1BKTv0HqmTZ3Pstj39o/mSL4VCsC1nMJyZBf0r87xN4jdF 0d9y1uiOMvoFA5WObEapsrDk/259EmrLKrRp37pM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Darrick J. Wong" , Christoph Hellwig , Amir Goldstein Subject: [PATCH 5.10 16/53] xfs: detect overflows in bmbt records Date: Fri, 3 Jun 2022 19:43:01 +0200 Message-Id: <20220603173819.194392585@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: "Darrick J. Wong" commit acf104c2331c1ba2a667e65dd36139d1555b1432 upstream. Detect file block mappings with a blockcount that's either so large that integer overflows occur or are zero, because neither are valid in the filesystem. Worse yet, attempting directory modifications causes the iext code to trip over the bmbt key handling and takes the filesystem down. We can fix most of this by preventing the bad metadata from entering the incore structures in the first place. Found by setting blockcount=0 in a directory data fork mapping and watching the fireworks. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman --- fs/xfs/libxfs/xfs_bmap.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/fs/xfs/libxfs/xfs_bmap.c +++ b/fs/xfs/libxfs/xfs_bmap.c @@ -6229,6 +6229,11 @@ xfs_bmap_validate_extent( xfs_fsblock_t endfsb; bool isrt; + if (irec->br_startblock + irec->br_blockcount <= irec->br_startblock) + return __this_address; + if (irec->br_startoff + irec->br_blockcount <= irec->br_startoff) + return __this_address; + isrt = XFS_IS_REALTIME_INODE(ip); endfsb = irec->br_startblock + irec->br_blockcount - 1; if (isrt && whichfork == XFS_DATA_FORK) {