From: ZhengYuan Huang <gality369@gmail.com>
To: dsterba@suse.com, clm@fb.com, idryomov@gmail.com
Cc: linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org,
baijiaju1990@gmail.com, r33s3n6@gmail.com, zzzccc427@gmail.com,
ZhengYuan Huang <gality369@gmail.com>
Subject: [PATCH v3 0/4] btrfs: fix balance NULL derefs and chunk/bg mapping verification
Date: Wed, 25 Mar 2026 08:43:35 +0800 [thread overview]
Message-ID: <20260325004339.2323838-1-gality369@gmail.com> (raw)
This series fixes three NULL dereferences in btrfs balance paths and the
underlying mount-time verification bug that lets the corresponding
chunk/block-group inconsistency go undetected.
The balance crashes happen when metadata corruption leaves a chunk present
in the chunk tree but without a corresponding block group in the in-memory
block group cache. In that case, balance reaches code paths that call
btrfs_lookup_block_group() and dereference the returned pointer without
checking for NULL.
The first three patches harden the affected balance paths:
- patch 1 fixes chunk_usage_filter()
- patch 2 fixes chunk_usage_range_filter()
- patch 3 fixes btrfs_may_alloc_data_chunk()
They are kept separate because the affected code was introduced by
different commits, which should also make backporting easier, as
suggested by Qu Wenruo.
The fourth patch fixes the mount-time verification side. Based on David
Sterba's feedback, it now explicitly relies on the mount-time context and
uses a lockless traversal of mapping_tree. check_chunk_block_group_mappings()
is supposed to verify that every chunk has a matching block group, but its
current iteration starts with btrfs_find_chunk_map(fs_info, 0, 1). If no
chunk contains logical address 0, the lookup returns NULL immediately and
the loop exits without checking any chunk at all. As a result, the
corrupted mapping can survive mount and only crash later when balance
reaches it.
This series makes btrfs reject the inconsistency earlier at mount time,
and also hardens the balance paths so the corruption is reported as
-EUCLEAN instead of triggering NULL dereferences.
[CHANGELOG]
v3:
- added a new patch to fix the same missing-block-group NULL dereference
in btrfs_may_alloc_data_chunk()
- patch 1 and 2:
- changed the bool return flow to explicit int error propagation
- used ret2 for the nested filter return value in should_balance_chunk()
- patch 4:
- reworked the changelog based on David Sterba's feedback
- clarified the mount-time context for the lockless mapping_tree traversal
v2:
- split the two balance filter fixes into separate patches
- reworked the chunk/block-group verification fix so the last patch
addresses the case where check_chunk_block_group_mappings() does not
actually iterate all chunk mappings
ZhengYuan Huang (4):
btrfs: balance: fix null-ptr-deref in chunk_usage_filter
btrfs: balance: fix null-ptr-deref in chunk_usage_range_filter
btrfs: balance: fix null-ptr-deref in btrfs_may_alloc_data_chunk
btrfs: fix check_chunk_block_group_mappings() to iterate all chunk maps
fs/btrfs/block-group.c | 24 ++++++----------
fs/btrfs/volumes.c | 63 ++++++++++++++++++++++++++++++------------
2 files changed, 55 insertions(+), 32 deletions(-)
--
2.43.0
next reply other threads:[~2026-03-25 0:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-25 0:43 ZhengYuan Huang [this message]
2026-03-25 0:43 ` [PATCH v3 1/4] btrfs: balance: fix null-ptr-deref in chunk_usage_filter ZhengYuan Huang
2026-03-25 0:43 ` [PATCH v3 2/4] btrfs: balance: fix null-ptr-deref in chunk_usage_range_filter ZhengYuan Huang
2026-03-25 0:43 ` [PATCH v3 3/4] btrfs: balance: fix null-ptr-deref in btrfs_may_alloc_data_chunk ZhengYuan Huang
2026-03-25 0:43 ` [PATCH v3 4/4] btrfs: fix check_chunk_block_group_mappings() to iterate all chunk maps ZhengYuan Huang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260325004339.2323838-1-gality369@gmail.com \
--to=gality369@gmail.com \
--cc=baijiaju1990@gmail.com \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=idryomov@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=r33s3n6@gmail.com \
--cc=zzzccc427@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox