From: Yichong Chen <chenyichong@uniontech.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org,
Andreas Dilger <adilger.kernel@dilger.ca>,
Baokun Li <libaokun@linux.alibaba.com>, Jan Kara <jack@suse.cz>,
Ojaswin Mujoo <ojaswin@linux.ibm.com>,
Ritesh Harjani <ritesh.list@gmail.com>,
Zhang Yi <yi.zhang@huawei.com>,
"Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>,
Yichong Chen <chenyichong@uniontech.com>
Subject: [PATCH] ext4: fix the logical block counter overflow in indirect migration
Date: Mon, 14 Sep 2026 14:55:44 +0800 [thread overview]
Message-ID: <20260914065544.3438431-1-chenyichong@uniontech.com> (raw)
update_tind_extent_range() advances lb->curr_block, an ext4_lblk_t, by
max_entries * max_entries for every empty triple-indirect slot. One
triple-indirect block spans max_entries^3 logical blocks, which exceeds
2^32 as soon as the block size is 8K or larger (16384^3 = 2^42 with 64K
blocks), so the counter wraps while that block is walked.
A wrapped counter makes the migration store a block number that is 2^32
blocks away from the one the pointer block describes. Two ranges can then
end up with the same ee_block, which trips
BUG_ON(newext->ee_block == nearex->ee_block) in ext4_ext_insert_extent(),
and without that collision the data is still moved to the wrong logical
block while the migration reports success.
Keep the counter in 64 bit so that it cannot wrap, and refuse the
migration with -EOPNOTSUPP when a data block is found after the last
logical block an extent can describe, which only a corrupt block map can
contain.
Fixes: c14c6fd5c56a ("ext4: Add EXT4_IOC_MIGRATE ioctl")
Signed-off-by: Yichong Chen <chenyichong@uniontech.com>
---
fs/ext4/migrate.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/fs/ext4/migrate.c b/fs/ext4/migrate.c
index e06d847033a1..8043959c19ef 100644
--- a/fs/ext4/migrate.c
+++ b/fs/ext4/migrate.c
@@ -14,7 +14,7 @@
* represented by a single extent
*/
struct migrate_struct {
- ext4_lblk_t first_block, last_block, curr_block;
+ u64 first_block, last_block, curr_block;
ext4_fsblk_t first_pblock, last_pblock;
};
@@ -65,6 +65,10 @@ static int update_extent_range(handle_t *handle, struct inode *inode,
ext4_fsblk_t pblock, struct migrate_struct *lb)
{
int retval;
+
+ if (lb->curr_block > (ext4_lblk_t)-1)
+ return -EOPNOTSUPP;
+
/*
* See if we can add on to the existing range (if it exists)
*/
--
2.51.0
next reply other threads:[~2026-09-14 6:57 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-14 6:55 Yichong Chen [this message]
2026-09-14 9:57 ` Jan Kara
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=20260914065544.3438431-1-chenyichong@uniontech.com \
--to=chenyichong@uniontech.com \
--cc=adilger.kernel@dilger.ca \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=jack@suse.cz \
--cc=libaokun@linux.alibaba.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ojaswin@linux.ibm.com \
--cc=ritesh.list@gmail.com \
--cc=tytso@mit.edu \
--cc=yi.zhang@huawei.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
all inboxes | Powered by JetHome®