Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp3552400ybb; Tue, 31 Mar 2020 07:31:43 -0700 (PDT) X-Google-Smtp-Source: ADFU+vtDboNVbmb7lBWZ+weggPmYKJJ+GeRBd3eqdrlCJuwUUJkVcro4iTPoa/v6E5k47YC7CgpS X-Received: by 2002:aca:cc0c:: with SMTP id c12mr2318169oig.6.1585665102621; Tue, 31 Mar 2020 07:31:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585665102; cv=none; d=google.com; s=arc-20160816; b=uHhXmxlMkGuZoGWsqfLlIKNTN4UqzOX7fD8LziusSbPWBBfwIQw2fbWXoyee1yqc1+ mLJOyidSJLh7QucydU7Zk0IK3FG3HzoLcume4O08csIwT0KGETXp6g5wkKzCO65zj7by ZMV9OZGCYD0pKasUvLEdVXA+NQH38l0py7veAnRiB/FibyHZ9PtwcKc3RpcyCm+1aajE JOCipmj+K7r45numAm2fRgeZsLVLDR88jME9vPYO0EN6ruLNX0Bu4kggFOBIDRKZCCWN sDYfbej78oqddN6+qwRK8engqICm157gZCNSBCSmTCRxPndiiUP8ciSQSxAkJiunvjis shhg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=Sf3YwiOGXfl3982ddXGnkNEDrs/pHGSGLfWpg6sLkg8=; b=OEqvNbTmVKXRJ2N7TClCOmkmaz28EjosUxIP71SBovogUODdt1/1cCDu1etl17Nlmi +VLx1FbxVgXCLi/lJsU1lMXB9f0IHn34eamHAzQ31blnjso38vQapGNA+GxnKErobEGy rL6szYuYuRHgeH0+vs0ZyQzi8HY8cCfguZcgTZmJysr5oniuyzEih4g60BUD1WZS++pZ hz/AVd1VVAjr4SGP897rmY9+Eb6Azw0tDeLroGOThezFoHvymx96SoFV2cAzX1rrsNC3 lEE/VFi8lAQ+QkJLDFjTGvNrhjCJM+SW/e/AmiF+288tIrVVJyOCj26u55dKxHiVRmFd bqUQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-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 f186si6653874oia.64.2020.03.31.07.31.25; Tue, 31 Mar 2020 07:31:42 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-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-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731249AbgCaOaj (ORCPT + 99 others); Tue, 31 Mar 2020 10:30:39 -0400 Received: from mx2.suse.de ([195.135.220.15]:58488 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731156AbgCaOai (ORCPT ); Tue, 31 Mar 2020 10:30:38 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 0E4ABACC6; Tue, 31 Mar 2020 14:30:37 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 4AE9D1E1214; Tue, 31 Mar 2020 16:30:35 +0200 (CEST) Date: Tue, 31 Mar 2020 16:30:35 +0200 From: Jan Kara To: Lukas Czerner Cc: Jan Kara , Ted Tso , linux-ext4@vger.kernel.org Subject: Re: [PATCH 2/2] ext2fs: Fix off-by-one in dx_grow_tree() Message-ID: <20200331143035.GB13528@quack2.suse.cz> References: <20200330090932.29445-1-jack@suse.cz> <20200330090932.29445-3-jack@suse.cz> <20200330132712.ckevhpof4vrsx5rw@work> <20200330145531.GF26544@quack2.suse.cz> <20200331113303.huhzo3jxdnhoupwv@work> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200331113303.huhzo3jxdnhoupwv@work> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Tue 31-03-20 13:33:03, Lukas Czerner wrote: > On Mon, Mar 30, 2020 at 04:55:31PM +0200, Jan Kara wrote: > > On Mon 30-03-20 15:27:12, Lukas Czerner wrote: > > > On Mon, Mar 30, 2020 at 11:09:32AM +0200, Jan Kara wrote: > > > > There is an off-by-one error in dx_grow_tree() when checking whether we > > > > can add another level to the tree. Thus we can grow tree too much > > > > leading to possible crashes in the library or corrupted filesystem. Fix > > > > the bug. > > > > > > Looks good, thanks > > > > > > Reviewed-by: Lukas Czerner > > > > > > Don't we have basically the same off-by-one in > > > e2fsck/pass1.c handle_htree() ? > > > > > > if ((root->indirect_levels > ext2_dir_htree_level(fs)) && > > > fix_problem(ctx, PR_1_HTREE_DEPTH, pctx)) > > > > I don't think so. It is indeed correct for root->indirect_levels to be > > equal to ext2_dir_htree_level(). However dx_grow_tree() is going to > > increase root->indirect_levels by 1 which is where tree would become > > invalid... > > > > Honza > > Hmm, are you sure ? I think the names are very confusing > > root->indirect_levels is zero based, while ext2_dir_htree_level() > returns the maximum number of levels (that is 3 by default). If I am > right then indirect_levels must always be smaller then > ext2_dir_htree_level() and that is how we use it everywhere else - the > palce I am pointing out is an exception and I think it's a bug. > > Indeed it looks like the bug got introduced in > 3f0cf647539970474be8f607017ca7eccfc2fbbe > > - if ((root->indirect_levels > 1) && > + if ((root->indirect_levels > ext2_dir_htree_level(fs)) && > > Or am I missing something ? Ah, you're indeed right! e2fsck/pass2.c even has a correct version of the condition. Just the condition in pass1.c is wrong. Honza > > -Lukas > > > > > > > > > > > Signed-off-by: Jan Kara > > > > --- > > > > lib/ext2fs/link.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/lib/ext2fs/link.c b/lib/ext2fs/link.c > > > > index 7b5bb022117c..469eea8cd06d 100644 > > > > --- a/lib/ext2fs/link.c > > > > +++ b/lib/ext2fs/link.c > > > > @@ -473,7 +473,7 @@ static errcode_t dx_grow_tree(ext2_filsys fs, ext2_ino_t dir, > > > > ext2fs_le16_to_cpu(info->frames[i].head->limit)) > > > > break; > > > > /* Need to grow tree depth? */ > > > > - if (i < 0 && info->levels > ext2_dir_htree_level(fs)) > > > > + if (i < 0 && info->levels >= ext2_dir_htree_level(fs)) > > > > return EXT2_ET_DIR_NO_SPACE; > > > > lblk = size / fs->blocksize; > > > > size += fs->blocksize; > > > > -- > > > > 2.16.4 > > > > > > > > > -- > > Jan Kara > > SUSE Labs, CR > > > -- Jan Kara SUSE Labs, CR