From: <gregkh@linuxfoundation.org>
To: gregkh@linuxfoundation.org,jack@suse.cz,libaokun1@huawei.com,patches@lists.linux.dev,ritesh.list@gmail.com,sashal@kernel.org,stable@kernel.org,tytso@mit.edu,yangerkun@huawei.com
Cc: <stable-commits@vger.kernel.org>
Subject: Patch "ext4: fix BUG in ext4_mb_new_inode_pa() due to overflow" has been added to the 5.15-stable tree
Date: Tue, 31 Oct 2023 14:38:43 +0100 [thread overview]
Message-ID: <2023103143-art-sampling-0262@gregkh> (raw)
In-Reply-To: <20231028064749.833278-2-libaokun1@huawei.com>
This is a note to let you know that I've just added the patch titled
ext4: fix BUG in ext4_mb_new_inode_pa() due to overflow
to the 5.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ext4-fix-bug-in-ext4_mb_new_inode_pa-due-to-overflow.patch
and it can be found in the queue-5.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
From stable-owner@vger.kernel.org Sat Oct 28 08:43:23 2023
From: Baokun Li <libaokun1@huawei.com>
Date: Sat, 28 Oct 2023 14:47:48 +0800
Subject: ext4: fix BUG in ext4_mb_new_inode_pa() due to overflow
To: <stable@vger.kernel.org>
Cc: <gregkh@linuxfoundation.org>, <sashal@kernel.org>, <tytso@mit.edu>, <jack@suse.cz>, <ritesh.list@gmail.com>, <patches@lists.linux.dev>, <yangerkun@huawei.com>, <libaokun1@huawei.com>, <stable@kernel.org>
Message-ID: <20231028064749.833278-2-libaokun1@huawei.com>
From: Baokun Li <libaokun1@huawei.com>
commit bc056e7163ac7db945366de219745cf94f32a3e6 upstream.
When we calculate the end position of ext4_free_extent, this position may
be exactly where ext4_lblk_t (i.e. uint) overflows. For example, if
ac_g_ex.fe_logical is 4294965248 and ac_orig_goal_len is 2048, then the
computed end is 0x100000000, which is 0. If ac->ac_o_ex.fe_logical is not
the first case of adjusting the best extent, that is, new_bex_end > 0, the
following BUG_ON will be triggered:
=========================================================
kernel BUG at fs/ext4/mballoc.c:5116!
invalid opcode: 0000 [#1] PREEMPT SMP PTI
CPU: 3 PID: 673 Comm: xfs_io Tainted: G E 6.5.0-rc1+ #279
RIP: 0010:ext4_mb_new_inode_pa+0xc5/0x430
Call Trace:
<TASK>
ext4_mb_use_best_found+0x203/0x2f0
ext4_mb_try_best_found+0x163/0x240
ext4_mb_regular_allocator+0x158/0x1550
ext4_mb_new_blocks+0x86a/0xe10
ext4_ext_map_blocks+0xb0c/0x13a0
ext4_map_blocks+0x2cd/0x8f0
ext4_iomap_begin+0x27b/0x400
iomap_iter+0x222/0x3d0
__iomap_dio_rw+0x243/0xcb0
iomap_dio_rw+0x16/0x80
=========================================================
A simple reproducer demonstrating the problem:
mkfs.ext4 -F /dev/sda -b 4096 100M
mount /dev/sda /tmp/test
fallocate -l1M /tmp/test/tmp
fallocate -l10M /tmp/test/file
fallocate -i -o 1M -l16777203M /tmp/test/file
fsstress -d /tmp/test -l 0 -n 100000 -p 8 &
sleep 10 && killall -9 fsstress
rm -f /tmp/test/tmp
xfs_io -c "open -ad /tmp/test/file" -c "pwrite -S 0xff 0 8192"
We simply refactor the logic for adjusting the best extent by adding
a temporary ext4_free_extent ex and use extent_logical_end() to avoid
overflow, which also simplifies the code.
Cc: stable@kernel.org # 6.4
Fixes: 93cdf49f6eca ("ext4: Fix best extent lstart adjustment logic in ext4_mb_new_inode_pa()")
Signed-off-by: Baokun Li <libaokun1@huawei.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Link: https://lore.kernel.org/r/20230724121059.11834-3-libaokun1@huawei.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Baokun Li <libaokun1@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/mballoc.c | 31 ++++++++++++++-----------------
1 file changed, 14 insertions(+), 17 deletions(-)
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -4664,8 +4664,11 @@ ext4_mb_new_inode_pa(struct ext4_allocat
pa = ac->ac_pa;
if (ac->ac_b_ex.fe_len < ac->ac_g_ex.fe_len) {
- int new_bex_start;
- int new_bex_end;
+ struct ext4_free_extent ex = {
+ .fe_logical = ac->ac_g_ex.fe_logical,
+ .fe_len = ac->ac_g_ex.fe_len,
+ };
+ loff_t orig_goal_end = extent_logical_end(sbi, &ex);
/* we can't allocate as much as normalizer wants.
* so, found space must get proper lstart
@@ -4684,29 +4687,23 @@ ext4_mb_new_inode_pa(struct ext4_allocat
* still cover original start
* 3. Else, keep the best ex at start of original request.
*/
- new_bex_end = ac->ac_g_ex.fe_logical +
- EXT4_C2B(sbi, ac->ac_g_ex.fe_len);
- new_bex_start = new_bex_end - EXT4_C2B(sbi, ac->ac_b_ex.fe_len);
- if (ac->ac_o_ex.fe_logical >= new_bex_start)
- goto adjust_bex;
+ ex.fe_len = ac->ac_b_ex.fe_len;
- new_bex_start = ac->ac_g_ex.fe_logical;
- new_bex_end =
- new_bex_start + EXT4_C2B(sbi, ac->ac_b_ex.fe_len);
- if (ac->ac_o_ex.fe_logical < new_bex_end)
+ ex.fe_logical = orig_goal_end - EXT4_C2B(sbi, ex.fe_len);
+ if (ac->ac_o_ex.fe_logical >= ex.fe_logical)
goto adjust_bex;
- new_bex_start = ac->ac_o_ex.fe_logical;
- new_bex_end =
- new_bex_start + EXT4_C2B(sbi, ac->ac_b_ex.fe_len);
+ ex.fe_logical = ac->ac_g_ex.fe_logical;
+ if (ac->ac_o_ex.fe_logical < extent_logical_end(sbi, &ex))
+ goto adjust_bex;
+ ex.fe_logical = ac->ac_o_ex.fe_logical;
adjust_bex:
- ac->ac_b_ex.fe_logical = new_bex_start;
+ ac->ac_b_ex.fe_logical = ex.fe_logical;
BUG_ON(ac->ac_o_ex.fe_logical < ac->ac_b_ex.fe_logical);
BUG_ON(ac->ac_o_ex.fe_len > ac->ac_b_ex.fe_len);
- BUG_ON(new_bex_end > (ac->ac_g_ex.fe_logical +
- EXT4_C2B(sbi, ac->ac_g_ex.fe_len)));
+ BUG_ON(extent_logical_end(sbi, &ex) > orig_goal_end);
}
/* preallocation can change ac_b_ex, thus we store actually
Patches currently in stable-queue which might be from stable-owner@vger.kernel.org are
queue-5.15/ext4-avoid-overlapping-preallocations-due-to-overflow.patch
queue-5.15/ext4-fix-bug-in-ext4_mb_new_inode_pa-due-to-overflow.patch
queue-5.15/ext4-add-two-helper-functions-extent_logical_end-and-pa_logical_end.patch
next prev parent reply other threads:[~2023-10-31 13:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-28 6:47 [PATCH 5.15 1/3] ext4: add two helper functions extent_logical_end() and pa_logical_end() Baokun Li
2023-10-28 6:47 ` [PATCH 5.15 2/3] ext4: fix BUG in ext4_mb_new_inode_pa() due to overflow Baokun Li
2023-10-31 13:38 ` gregkh [this message]
2023-10-31 13:39 ` Patch "ext4: fix BUG in ext4_mb_new_inode_pa() due to overflow" has been added to the 6.1-stable tree gregkh
2023-10-28 6:47 ` [PATCH 5.15 3/3] ext4: avoid overlapping preallocations due to overflow Baokun Li
2023-10-31 13:38 ` Patch "ext4: avoid overlapping preallocations due to overflow" has been added to the 5.15-stable tree gregkh
2023-10-31 13:39 ` Patch "ext4: avoid overlapping preallocations due to overflow" has been added to the 6.1-stable tree gregkh
2023-10-31 12:51 ` [PATCH 5.15 1/3] ext4: add two helper functions extent_logical_end() and pa_logical_end() Greg KH
2023-10-31 13:17 ` Baokun Li
2023-10-31 14:11 ` Greg KH
2023-11-01 1:47 ` Baokun Li
2023-10-31 13:38 ` Patch "ext4: add two helper functions extent_logical_end() and pa_logical_end()" has been added to the 5.15-stable tree gregkh
2023-10-31 13:39 ` Patch "ext4: add two helper functions extent_logical_end() and pa_logical_end()" has been added to the 6.1-stable tree gregkh
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=2023103143-art-sampling-0262@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=jack@suse.cz \
--cc=libaokun1@huawei.com \
--cc=patches@lists.linux.dev \
--cc=ritesh.list@gmail.com \
--cc=sashal@kernel.org \
--cc=stable-commits@vger.kernel.org \
--cc=stable@kernel.org \
--cc=tytso@mit.edu \
--cc=yangerkun@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.