Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp195062imw; Mon, 4 Jul 2022 07:35:27 -0700 (PDT) X-Google-Smtp-Source: AGRyM1ufVqNLIfQ3/L0+Lo1zej7sVyTDE6QZstHGS9SPprPK3zWiUhB4itJ3A2oIL1tKHpdQlBml X-Received: by 2002:a17:90b:4f89:b0:1ec:a57c:eee8 with SMTP id qe9-20020a17090b4f8900b001eca57ceee8mr36735917pjb.220.1656945327627; Mon, 04 Jul 2022 07:35:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656945327; cv=none; d=google.com; s=arc-20160816; b=u+RTks/o2OKR20gIC1TCVGP0dEIVtizdmGjs4bunCbp1rYqAvoU4G26WvhnqCikYdB 7wKNJVshXaZPLA9C1LfKNIfsoh62yDJmzkhwVaFkAIW0pTbOwRv/A6ZHLpcH3Q8E53YE VlnCWITpHRXP7ATs8E2htaoiyWPtz40MRKQyIRoQEpXBMqMgHv8eT/bQTa2zebUbU75f 61RmCfEZbifVLVGEN0FigE+slY9qCrSmUuLrF8B11LZq6tyyZLNqmn2Kj1kiJOaUM/XQ vm/PXVxfUcf1sG8KsP3FqZFLW39FVyLN3ypDZ0Bx37rFHHNnBL13Hfy6HRrDHtaXGaQ9 pCxw== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=yFheRc6ahFYZU0nsUZgmnAMawQpOetoOvsCOk95T5Y4=; b=QLtPCzt3F18UytqlMD+qrWw7DQmpfLwD7ItM76qis2oD4WQciWmotZwf7rXxLHg+5f o1pAEquOYKPhrIJttnOpSM49t0oyB0VJZ6MupA8NYTRuqP+PTamkzL72uUHR2gBkemlO FcpcAZg8zXEHEqr9g8GiBCH2VTdyWK6UzO0RDdBcBGU2VX3EXXs8Kmg0ZPrQ7VxIOyTf keNIxhfFij2sKREXxnieLg2MrSVZUQH362Oav3/Snp8e0oZe7EQapDAHTL51JTAI9D+w UFj2jcKcUvM5URjkMNsJheDgqbCOwb/SVJZk31A0BDcjQidUadwPyfjDGUuaNoJslbs4 9t5w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=itZflsLx; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ob2-20020a17090b390200b001eccaceca54si14272114pjb.80.2022.07.04.07.35.15; Mon, 04 Jul 2022 07:35:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=itZflsLx; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234447AbiGDO2V (ORCPT + 99 others); Mon, 4 Jul 2022 10:28:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58262 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234428AbiGDO11 (ORCPT ); Mon, 4 Jul 2022 10:27:27 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id E5F57636A for ; Mon, 4 Jul 2022 07:27:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1656944845; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yFheRc6ahFYZU0nsUZgmnAMawQpOetoOvsCOk95T5Y4=; b=itZflsLxVcC3qBmvCd8YpagDDQbwQz02gP3GI6ISywSMM3QHIB9HT1tpkx7mDP2zrEZNb2 nC8RqxwovxSl/zg4ogrJeBG6XZVRLZu3gTF3hZSEntTVl3DKHhnSmKIWJtNRMKLawY2omY xriJTTKazyRKg2+S0LnWGYB24TWBdAQ= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-407-mtI9X-EcOE6Lom9y5T3Zlw-1; Mon, 04 Jul 2022 10:27:24 -0400 X-MC-Unique: mtI9X-EcOE6Lom9y5T3Zlw-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0D8871035341; Mon, 4 Jul 2022 14:27:24 +0000 (UTC) Received: from fedora.redhat.com (unknown [10.40.193.8]) by smtp.corp.redhat.com (Postfix) with ESMTP id 830D2492C3B; Mon, 4 Jul 2022 14:27:23 +0000 (UTC) From: Lukas Czerner To: linux-ext4@vger.kernel.org Cc: tytso@mit.edu Subject: [PATCH 2/2] ext4: make sure ext4_append() always allocates new block Date: Mon, 4 Jul 2022 16:27:21 +0200 Message-Id: <20220704142721.157985-2-lczerner@redhat.com> In-Reply-To: <20220704142721.157985-1-lczerner@redhat.com> References: <20220704142721.157985-1-lczerner@redhat.com> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.85 on 10.11.54.9 X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham 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-ext4@vger.kernel.org ext4_append() must always allocate a new block, otherwise we run the risk of overwriting existing directory block corrupting the directory tree in the process resulting in all manner of problems later on. Add a sanity check to see if the logical block is already allocated and error out if it is. Signed-off-by: Lukas Czerner --- fs/ext4/namei.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c index cf460aa4f81d..4af441494e09 100644 --- a/fs/ext4/namei.c +++ b/fs/ext4/namei.c @@ -54,6 +54,7 @@ static struct buffer_head *ext4_append(handle_t *handle, struct inode *inode, ext4_lblk_t *block) { + struct ext4_map_blocks map; struct buffer_head *bh; int err; @@ -63,6 +64,21 @@ static struct buffer_head *ext4_append(handle_t *handle, return ERR_PTR(-ENOSPC); *block = inode->i_size >> inode->i_sb->s_blocksize_bits; + map.m_lblk = *block; + map.m_len = 1; + + /* + * We're appending new directory block. Make sure the block is not + * allocated yet, otherwise we will end up corrupting the + * directory. + */ + err = ext4_map_blocks(NULL, inode, &map, 0); + if (err < 0) + return ERR_PTR(err); + if (err) { + EXT4_ERROR_INODE(inode, "Logical block already allocated"); + return ERR_PTR(-EFSCORRUPTED); + } bh = ext4_bread(handle, inode, *block, EXT4_GET_BLOCKS_CREATE); if (IS_ERR(bh)) -- 2.35.3