diff mbox series

[v2] ext4: fix off by one issue in alloc_flex_gd()

Message ID 20240927133329.1015041-1-libaokun@huaweicloud.com
State Awaiting Upstream
Headers show
Series [v2] ext4: fix off by one issue in alloc_flex_gd() | expand

Commit Message

Baokun Li Sept. 27, 2024, 1:33 p.m. UTC
From: Baokun Li <libaokun1@huawei.com>

Wesley reported an issue:

==================================================================
EXT4-fs (dm-5): resizing filesystem from 7168 to 786432 blocks
------------[ cut here ]------------
kernel BUG at fs/ext4/resize.c:324!
CPU: 9 UID: 0 PID: 3576 Comm: resize2fs Not tainted 6.11.0+ #27
RIP: 0010:ext4_resize_fs+0x1212/0x12d0
Call Trace:
 __ext4_ioctl+0x4e0/0x1800
 ext4_ioctl+0x12/0x20
 __x64_sys_ioctl+0x99/0xd0
 x64_sys_call+0x1206/0x20d0
 do_syscall_64+0x72/0x110
 entry_SYSCALL_64_after_hwframe+0x76/0x7e
==================================================================

While reviewing the patch, Honza found that when adjusting resize_bg in
alloc_flex_gd(), it was possible for flex_gd->resize_bg to be bigger than
flexbg_size.

The reproduction of the problem requires the following:

 o_group = flexbg_size * 2 * n;
 o_size = (o_group + 1) * group_size;
 n_group: [o_group + flexbg_size, o_group + flexbg_size * 2)
 o_size = (n_group + 1) * group_size;

Take n=0,flexbg_size=16 as an example:

              last:15
|o---------------|--------------n-|
o_group:0    resize to      n_group:30

The corresponding reproducer is:

img=test.img
truncate -s 600M $img
mkfs.ext4 -F $img -b 1024 -G 16 8M
dev=`losetup -f --show $img`
mkdir -p /tmp/test
mount $dev /tmp/test
resize2fs $dev 248M

Delete the problematic plus 1 to fix the issue, and add a WARN_ON_ONCE()
to prevent the issue from happening again.

Reported-by: Wesley Hershberger <wesley.hershberger@canonical.com>
Closes: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2081231
Reported-by: Stéphane Graber <stgraber@stgraber.org>
Closes: https://lore.kernel.org/all/20240925143325.518508-1-aleksandr.mikhalitsyn@canonical.com/
Tested-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
Tested-by: Eric Sandeen <sandeen@redhat.com>
Fixes: 665d3e0af4d3 ("ext4: reduce unnecessary memory allocation in alloc_flex_gd()")
Cc: stable@vger.kernel.org
Signed-off-by: Baokun Li <libaokun1@huawei.com>
---
Changes since v1:
 * Add missing WARN_ON_ONCE().
 * Correct the comment of alloc_flex_gd().

 fs/ext4/resize.c | 18 ++++++++++--------
 1 file changed, 10 insertions(+), 8 deletions(-)

Comments

Eric Sandeen Sept. 27, 2024, 2:14 p.m. UTC | #1
On 9/27/24 8:33 AM, libaokun@huaweicloud.com wrote:
> From: Baokun Li <libaokun1@huawei.com>
> 

...

> Delete the problematic plus 1 to fix the issue, and add a WARN_ON_ONCE()
> to prevent the issue from happening again.
> 
> Reported-by: Wesley Hershberger <wesley.hershberger@canonical.com>
> Closes: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2081231
> Reported-by: Stéphane Graber <stgraber@stgraber.org>
> Closes: https://lore.kernel.org/all/20240925143325.518508-1-aleksandr.mikhalitsyn@canonical.com/
> Tested-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
> Tested-by: Eric Sandeen <sandeen@redhat.com>

The patch has changed a little since I tested, but it still passes my testcase
(as expected, no WARN ON etc) so looks good from that POV, thanks!
-Eric
Baokun Li Sept. 29, 2024, 1:29 a.m. UTC | #2
On 2024/9/27 22:14, Eric Sandeen wrote:
> On 9/27/24 8:33 AM, libaokun@huaweicloud.com wrote:
>> From: Baokun Li <libaokun1@huawei.com>
>>
> ...
>
>> Delete the problematic plus 1 to fix the issue, and add a WARN_ON_ONCE()
>> to prevent the issue from happening again.
>>
>> Reported-by: Wesley Hershberger <wesley.hershberger@canonical.com>
>> Closes: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2081231
>> Reported-by: Stéphane Graber <stgraber@stgraber.org>
>> Closes: https://lore.kernel.org/all/20240925143325.518508-1-aleksandr.mikhalitsyn@canonical.com/
>> Tested-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
>> Tested-by: Eric Sandeen <sandeen@redhat.com>
> The patch has changed a little since I tested, but it still passes my testcase
> (as expected, no WARN ON etc) so looks good from that POV, thanks!
> -Eric

Hi Eric,

Thanks for testing it again!

The core modification logic remains unchanged from before.
Just added a max_resize_bg variable for exception fixing.

It is necessary to ensure that flex_gd->resize_bg does not exceed the
smaller of flexbg_size and MAX_RESIZE_BG before it is used. So we need
to record max_resize_bg, warn on resize_bg adjustment logic exceptions,
and use max_resize_bg to avoid subsequent resize complaints.
Jan Kara Sept. 30, 2024, 9:57 a.m. UTC | #3
On Fri 27-09-24 21:33:29, libaokun@huaweicloud.com wrote:
> From: Baokun Li <libaokun1@huawei.com>
> 
> Wesley reported an issue:
> 
> ==================================================================
> EXT4-fs (dm-5): resizing filesystem from 7168 to 786432 blocks
> ------------[ cut here ]------------
> kernel BUG at fs/ext4/resize.c:324!
> CPU: 9 UID: 0 PID: 3576 Comm: resize2fs Not tainted 6.11.0+ #27
> RIP: 0010:ext4_resize_fs+0x1212/0x12d0
> Call Trace:
>  __ext4_ioctl+0x4e0/0x1800
>  ext4_ioctl+0x12/0x20
>  __x64_sys_ioctl+0x99/0xd0
>  x64_sys_call+0x1206/0x20d0
>  do_syscall_64+0x72/0x110
>  entry_SYSCALL_64_after_hwframe+0x76/0x7e
> ==================================================================
> 
> While reviewing the patch, Honza found that when adjusting resize_bg in
> alloc_flex_gd(), it was possible for flex_gd->resize_bg to be bigger than
> flexbg_size.
> 
> The reproduction of the problem requires the following:
> 
>  o_group = flexbg_size * 2 * n;
>  o_size = (o_group + 1) * group_size;
>  n_group: [o_group + flexbg_size, o_group + flexbg_size * 2)
>  o_size = (n_group + 1) * group_size;
> 
> Take n=0,flexbg_size=16 as an example:
> 
>               last:15
> |o---------------|--------------n-|
> o_group:0    resize to      n_group:30
> 
> The corresponding reproducer is:
> 
> img=test.img
> truncate -s 600M $img
> mkfs.ext4 -F $img -b 1024 -G 16 8M
> dev=`losetup -f --show $img`
> mkdir -p /tmp/test
> mount $dev /tmp/test
> resize2fs $dev 248M
> 
> Delete the problematic plus 1 to fix the issue, and add a WARN_ON_ONCE()
> to prevent the issue from happening again.
> 
> Reported-by: Wesley Hershberger <wesley.hershberger@canonical.com>
> Closes: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2081231
> Reported-by: Stéphane Graber <stgraber@stgraber.org>
> Closes: https://lore.kernel.org/all/20240925143325.518508-1-aleksandr.mikhalitsyn@canonical.com/
> Tested-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
> Tested-by: Eric Sandeen <sandeen@redhat.com>
> Fixes: 665d3e0af4d3 ("ext4: reduce unnecessary memory allocation in alloc_flex_gd()")
> Cc: stable@vger.kernel.org
> Signed-off-by: Baokun Li <libaokun1@huawei.com>

Looks good. Feel free to add:

Reviewed-by: Jan Kara <jack@suse.cz>

								Honza

> ---
> Changes since v1:
>  * Add missing WARN_ON_ONCE().
>  * Correct the comment of alloc_flex_gd().
> 
>  fs/ext4/resize.c | 18 ++++++++++--------
>  1 file changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c
> index e04eb08b9060..a2704f064361 100644
> --- a/fs/ext4/resize.c
> +++ b/fs/ext4/resize.c
> @@ -230,8 +230,8 @@ struct ext4_new_flex_group_data {
>  #define MAX_RESIZE_BG				16384
>  
>  /*
> - * alloc_flex_gd() allocates a ext4_new_flex_group_data with size of
> - * @flexbg_size.
> + * alloc_flex_gd() allocates an ext4_new_flex_group_data that satisfies the
> + * resizing from @o_group to @n_group, its size is typically @flexbg_size.
>   *
>   * Returns NULL on failure otherwise address of the allocated structure.
>   */
> @@ -239,25 +239,27 @@ static struct ext4_new_flex_group_data *alloc_flex_gd(unsigned int flexbg_size,
>  				ext4_group_t o_group, ext4_group_t n_group)
>  {
>  	ext4_group_t last_group;
> +	unsigned int max_resize_bg;
>  	struct ext4_new_flex_group_data *flex_gd;
>  
>  	flex_gd = kmalloc(sizeof(*flex_gd), GFP_NOFS);
>  	if (flex_gd == NULL)
>  		goto out3;
>  
> -	if (unlikely(flexbg_size > MAX_RESIZE_BG))
> -		flex_gd->resize_bg = MAX_RESIZE_BG;
> -	else
> -		flex_gd->resize_bg = flexbg_size;
> +	max_resize_bg = umin(flexbg_size, MAX_RESIZE_BG);
> +	flex_gd->resize_bg = max_resize_bg;
>  
>  	/* Avoid allocating large 'groups' array if not needed */
>  	last_group = o_group | (flex_gd->resize_bg - 1);
>  	if (n_group <= last_group)
> -		flex_gd->resize_bg = 1 << fls(n_group - o_group + 1);
> +		flex_gd->resize_bg = 1 << fls(n_group - o_group);
>  	else if (n_group - last_group < flex_gd->resize_bg)
> -		flex_gd->resize_bg = 1 << max(fls(last_group - o_group + 1),
> +		flex_gd->resize_bg = 1 << max(fls(last_group - o_group),
>  					      fls(n_group - last_group));
>  
> +	if (WARN_ON_ONCE(flex_gd->resize_bg > max_resize_bg))
> +		flex_gd->resize_bg = max_resize_bg;
> +
>  	flex_gd->groups = kmalloc_array(flex_gd->resize_bg,
>  					sizeof(struct ext4_new_group_data),
>  					GFP_NOFS);
> -- 
> 2.39.2
>
Theodore Ts'o Oct. 5, 2024, 2:40 a.m. UTC | #4
On Fri, 27 Sep 2024 21:33:29 +0800, libaokun@huaweicloud.com wrote:
> Wesley reported an issue:
> 
> ==================================================================
> EXT4-fs (dm-5): resizing filesystem from 7168 to 786432 blocks
> ------------[ cut here ]------------
> kernel BUG at fs/ext4/resize.c:324!
> CPU: 9 UID: 0 PID: 3576 Comm: resize2fs Not tainted 6.11.0+ #27
> RIP: 0010:ext4_resize_fs+0x1212/0x12d0
> Call Trace:
>  __ext4_ioctl+0x4e0/0x1800
>  ext4_ioctl+0x12/0x20
>  __x64_sys_ioctl+0x99/0xd0
>  x64_sys_call+0x1206/0x20d0
>  do_syscall_64+0x72/0x110
>  entry_SYSCALL_64_after_hwframe+0x76/0x7e
> ==================================================================
> 
> [...]

Applied, thanks!

[1/1] ext4: fix off by one issue in alloc_flex_gd()
      commit: 6121258c2b33ceac3d21f6a221452692c465df88

Best regards,
diff mbox series

Patch

diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c
index e04eb08b9060..a2704f064361 100644
--- a/fs/ext4/resize.c
+++ b/fs/ext4/resize.c
@@ -230,8 +230,8 @@  struct ext4_new_flex_group_data {
 #define MAX_RESIZE_BG				16384
 
 /*
- * alloc_flex_gd() allocates a ext4_new_flex_group_data with size of
- * @flexbg_size.
+ * alloc_flex_gd() allocates an ext4_new_flex_group_data that satisfies the
+ * resizing from @o_group to @n_group, its size is typically @flexbg_size.
  *
  * Returns NULL on failure otherwise address of the allocated structure.
  */
@@ -239,25 +239,27 @@  static struct ext4_new_flex_group_data *alloc_flex_gd(unsigned int flexbg_size,
 				ext4_group_t o_group, ext4_group_t n_group)
 {
 	ext4_group_t last_group;
+	unsigned int max_resize_bg;
 	struct ext4_new_flex_group_data *flex_gd;
 
 	flex_gd = kmalloc(sizeof(*flex_gd), GFP_NOFS);
 	if (flex_gd == NULL)
 		goto out3;
 
-	if (unlikely(flexbg_size > MAX_RESIZE_BG))
-		flex_gd->resize_bg = MAX_RESIZE_BG;
-	else
-		flex_gd->resize_bg = flexbg_size;
+	max_resize_bg = umin(flexbg_size, MAX_RESIZE_BG);
+	flex_gd->resize_bg = max_resize_bg;
 
 	/* Avoid allocating large 'groups' array if not needed */
 	last_group = o_group | (flex_gd->resize_bg - 1);
 	if (n_group <= last_group)
-		flex_gd->resize_bg = 1 << fls(n_group - o_group + 1);
+		flex_gd->resize_bg = 1 << fls(n_group - o_group);
 	else if (n_group - last_group < flex_gd->resize_bg)
-		flex_gd->resize_bg = 1 << max(fls(last_group - o_group + 1),
+		flex_gd->resize_bg = 1 << max(fls(last_group - o_group),
 					      fls(n_group - last_group));
 
+	if (WARN_ON_ONCE(flex_gd->resize_bg > max_resize_bg))
+		flex_gd->resize_bg = max_resize_bg;
+
 	flex_gd->groups = kmalloc_array(flex_gd->resize_bg,
 					sizeof(struct ext4_new_group_data),
 					GFP_NOFS);