From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8A9DF297110; Mon, 12 May 2025 18:04:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747073076; cv=none; b=utPqOlUjMD+JrCTukTZgScKYPjPxabN3QKk2/nW1B318TbZrzRM7IE1y6vZeIlCUikIgv5EH4jHAB//XNBCYACVmJ96LDeK30u6MN9eDySI1JMYiQ7JElhg61dFPKCUEj9wDgDXWXnsBg+ZIxlwF3uN4NvLSdc0URaBoetaFF4A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747073076; c=relaxed/simple; bh=wqPawSn35KKJsD+IQUqIzvs2uEVsFWTnTnCKW6tq/Zg=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=IVIsMpj183z8NVoCaueX2spluLowCh/ETsTM5XPyWs8S3ABlRs3HVQ9c8/ctXNYY8syNYRRgfEERrLabZkV0WJdeR9umVVDbICFQtHqXlcW7TS5n/QupQF7hUhbpkFYeFru32KX1uHr9NCCaSDGYC1pvsbc+0hUgE8p6gVdGOXE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=k8fQybZL; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="k8fQybZL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4866CC4CEE7; Mon, 12 May 2025 18:04:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747073076; bh=wqPawSn35KKJsD+IQUqIzvs2uEVsFWTnTnCKW6tq/Zg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=k8fQybZLknZXnH4CmAIqJ4o8rO1+VZBd7ISJAY03ml6dbzcFidkfFNx4ExvvyXZQ9 c7EfXEJ/vdCVBbrTBakT73Avq1ZHkrdr9XfxQDCg1BjYVUUb0Il9ruq2Aotd9RjZy9 02e4uEKT5JNOYEeF1oFEN/bgCcvFzh1OmbAcfbUvrryK3JL9zqoYPsT/bOm2tCGeYb 7AMV9X/ozDSGMdWHWPumGjvFOXSA0sfAyaBw5yY41Ic3q2UL2d+Nh+gT70pF16NDyu sxJ24K3XQhHq24rsn5iuTB5W0YGKmeaaT8FPLUss1c1aqKPsUlgteZ5+7KOnVX7vGj tY6jND9B4fjYw== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Qu Wenruo , Johannes Thumshirn , David Sterba , Sasha Levin , clm@fb.com, josef@toxicpanda.com, linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH AUTOSEL 6.12 04/11] btrfs: avoid NULL pointer dereference if no valid csum tree Date: Mon, 12 May 2025 14:04:19 -0400 Message-Id: <20250512180426.437627-4-sashal@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250512180426.437627-1-sashal@kernel.org> References: <20250512180426.437627-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-btrfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.12.28 Content-Transfer-Encoding: 8bit From: Qu Wenruo [ Upstream commit f95d186255b319c48a365d47b69bd997fecb674e ] [BUG] When trying read-only scrub on a btrfs with rescue=idatacsums mount option, it will crash with the following call trace: BUG: kernel NULL pointer dereference, address: 0000000000000208 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page CPU: 1 UID: 0 PID: 835 Comm: btrfs Tainted: G O 6.15.0-rc3-custom+ #236 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:btrfs_lookup_csums_bitmap+0x49/0x480 [btrfs] Call Trace: scrub_find_fill_first_stripe+0x35b/0x3d0 [btrfs] scrub_simple_mirror+0x175/0x290 [btrfs] scrub_stripe+0x5f7/0x6f0 [btrfs] scrub_chunk+0x9a/0x150 [btrfs] scrub_enumerate_chunks+0x333/0x660 [btrfs] btrfs_scrub_dev+0x23e/0x600 [btrfs] btrfs_ioctl+0x1dcf/0x2f80 [btrfs] __x64_sys_ioctl+0x97/0xc0 do_syscall_64+0x4f/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e [CAUSE] Mount option "rescue=idatacsums" will completely skip loading the csum tree, so that any data read will not find any data csum thus we will ignore data checksum verification. Normally call sites utilizing csum tree will check the fs state flag NO_DATA_CSUMS bit, but unfortunately scrub does not check that bit at all. This results in scrub to call btrfs_search_slot() on a NULL pointer and triggered above crash. [FIX] Check both extent and csum tree root before doing any tree search. Reviewed-by: Johannes Thumshirn Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin --- fs/btrfs/scrub.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c index c73a41b1ad560..d8fcc3eb85c88 100644 --- a/fs/btrfs/scrub.c +++ b/fs/btrfs/scrub.c @@ -1541,8 +1541,8 @@ static int scrub_find_fill_first_stripe(struct btrfs_block_group *bg, u64 extent_gen; int ret; - if (unlikely(!extent_root)) { - btrfs_err(fs_info, "no valid extent root for scrub"); + if (unlikely(!extent_root || !csum_root)) { + btrfs_err(fs_info, "no valid extent or csum root for scrub"); return -EUCLEAN; } memset(stripe->sectors, 0, sizeof(struct scrub_sector_verification) * -- 2.39.5