From patchwork Thu May 18 01:02:21 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Cengiz Can X-Patchwork-Id: 1783009 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Authentication-Results: legolas.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=canonical.com header.i=@canonical.com header.a=rsa-sha256 header.s=20210705 header.b=iC7DCR/Q; dkim-atps=neutral Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4QMBXs2lLJz20dv for ; Thu, 18 May 2023 11:02:51 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1pzS2L-0004vA-Vn; Thu, 18 May 2023 01:02:33 +0000 Received: from smtp-relay-internal-0.internal ([10.131.114.225] helo=smtp-relay-internal-0.canonical.com) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1pzS2K-0004uz-CQ for kernel-team@lists.ubuntu.com; Thu, 18 May 2023 01:02:32 +0000 Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com [209.85.218.69]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id 1EB8F3F177 for ; Thu, 18 May 2023 01:02:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1684371751; bh=HNrxi/pL+H1+2jIPPNq9DI85Su/FL1hHHZORkYpdlhw=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=iC7DCR/QFUnKH4rWJJAwgzr2siW8KO7tsD3xtzHfs5gllmmN8X2wijNrxfIAYkDU5 q3MwL+T4X22d29yDeY4DVglqHPtN615nfBG2UAGzASjmeXCuzp/oimwJ2dkZ+KVJFD dfgrbRvf3U0zurSYzVOgw81YwCu7s/OEHdTW2nrWr14CrgD6Iod8SjxhUN46RgzfbB DDR45lT6+X5Z43vGswW9xAyV1dIn2GyK2HVXSTOUIbuxe1CZavmxhQWepVKho5R5X9 J5Nt4AtF1IsNNuY7J+Pl7HZDFL2VuxgwtToMtC4vsVmvsTd4waj3LxxFywXFYlsSXZ uWkwIh+Nr5LZw== Received: by mail-ej1-f69.google.com with SMTP id a640c23a62f3a-96ae3faf801so204350466b.3 for ; Wed, 17 May 2023 18:02:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684371750; x=1686963750; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HNrxi/pL+H1+2jIPPNq9DI85Su/FL1hHHZORkYpdlhw=; b=QvYaCr6cfTFSgYIVlq36Ff63c9TW20YmwrMhkcIf7bI0+KhWxqmPosvdId1DbJf5Zh JAIIGrUZ7092e5DR1rFFXrUkvjyr4AhQ1S4c+Bxfvk3HCSqm+QH8H40fa0gM3g3wY19w htnnY5SaTzTKGtYq8NE1xfprA2LfbLMAOah7K26ZO6iS6priCwJRTnUjYQd6WzaLWIrc P8T1Hd93ISP4IXhEUS7SasCIjXW7FlODmlcrN4+N2g7eL/VSiWO9hAKetQCqFyiF9i1H Z8ADY6Z3FA5NHsnMSdWm80fn8f5qH4ryWEEsK9j2JkhD15L9m+ZLpW4wwVdLqWcsRu8P 90RQ== X-Gm-Message-State: AC+VfDyEaWb/MPWXQAaesse+jbKFTlLVE5zQ7G48cOgLIGn0xZYV2frx k9q/8/bkvEh7zXRff66v0R9J9aTUNwjK3H8xJGXZ98zye27PubHWVs0+uYPUlkQ8uOhUoPEwMJM CbYzK4ehK/ciJvCvqWCYjeHTk2mHyBf4i7oHnJYzvPly2w0GI/3GjxXY= X-Received: by 2002:a17:907:2daa:b0:94e:dbf7:2dfe with SMTP id gt42-20020a1709072daa00b0094edbf72dfemr43206173ejc.11.1684371750326; Wed, 17 May 2023 18:02:30 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6n2+RUNrHapZagf4Cfk44tzi5Hpgj0BWn/He5LsjrK4Z0X3kslalt2Ye1eP6jyKzV77F9aGg== X-Received: by 2002:a17:907:2daa:b0:94e:dbf7:2dfe with SMTP id gt42-20020a1709072daa00b0094edbf72dfemr43206159ejc.11.1684371749966; Wed, 17 May 2023 18:02:29 -0700 (PDT) Received: from localhost ([82.222.124.85]) by smtp.gmail.com with ESMTPSA id jo8-20020a170906f6c800b00969f44bbef3sm267598ejb.11.2023.05.17.18.02.29 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 May 2023 18:02:29 -0700 (PDT) From: Cengiz Can To: kernel-team@lists.ubuntu.com Subject: [SRU Focal PATCH 1/2] ext4: check if directory block is within i_size Date: Thu, 18 May 2023 04:02:21 +0300 Message-Id: <20230518010221.163474-1-cengiz.can@canonical.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230517161227.141529-1-cengiz.can@canonical.com> References: <20230517161227.141529-1-cengiz.can@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Lukas Czerner Currently ext4 directory handling code implicitly assumes that the directory blocks are always within the i_size. In fact ext4_append() will attempt to allocate next directory block based solely on i_size and the i_size is then appropriately increased after a successful allocation. However, for this to work it requires i_size to be correct. If, for any reason, the directory inode i_size is corrupted in a way that the directory tree refers to a valid directory block past i_size, we could end up corrupting parts of the directory tree structure by overwriting already used directory blocks when modifying the directory. Fix it by catching the corruption early in __ext4_read_dirblock(). Addresses Red-Hat-Bugzilla: #2070205 CVE: CVE-2022-1184 Signed-off-by: Lukas Czerner Cc: stable@vger.kernel.org Reviewed-by: Andreas Dilger Link: https://lore.kernel.org/r/20220704142721.157985-1-lczerner@redhat.com Signed-off-by: Theodore Ts'o CVE-2022-1184 (cherry picked from commit 65f8ea4cd57dbd46ea13b41dc8bac03176b04233) Signed-off-by: Cengiz Can --- fs/ext4/namei.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c index 4e94b6bd99bc..db008809fa40 100644 --- a/fs/ext4/namei.c +++ b/fs/ext4/namei.c @@ -125,6 +125,13 @@ static struct buffer_head *__ext4_read_dirblock(struct inode *inode, struct ext4_dir_entry *dirent; int is_dx_block = 0; + if (block >= inode->i_size) { + ext4_error_inode(inode, func, line, block, + "Attempting to read directory block (%u) that is past i_size (%llu)", + block, inode->i_size); + return ERR_PTR(-EFSCORRUPTED); + } + if (ext4_simulate_fail(inode->i_sb, EXT4_SIM_DIRBLOCK_EIO)) bh = ERR_PTR(-EIO); else