As pointed out in the documentation, calling 'kmalloc' with open-coded
arithmetic can lead to unfortunate overflows and this particular way of
using it has been deprecated. Instead, it's preferred to use
'kmalloc_array' in cases where it might apply so an overflow check is
performed.

Signed-off-by: Miquel Sabaté Solà <mssola@mssola.com>
---
 fs/btrfs/delayed-inode.c | 4 ++--
 fs/btrfs/tree-log.c      | 9 +++------
 2 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c
index 6adfe62cd0c4..81577a0c601f 100644
--- a/fs/btrfs/delayed-inode.c
+++ b/fs/btrfs/delayed-inode.c
@@ -738,8 +738,8 @@ static int btrfs_insert_delayed_item(struct btrfs_trans_handle *trans,
 		u32 *ins_sizes;
 		int i = 0;
 
-		ins_data = kmalloc(batch.nr * sizeof(u32) +
-				   batch.nr * sizeof(struct btrfs_key), GFP_NOFS);
+		ins_data = kmalloc_array(batch.nr,
+					 sizeof(u32) + sizeof(struct btrfs_key), GFP_NOFS);
 		if (!ins_data) {
 			ret = -ENOMEM;
 			goto out;
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 7d19a8c5b2a3..d6471cd33f7f 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -4062,8 +4062,7 @@ static int flush_dir_items_batch(struct btrfs_trans_handle *trans,
 		struct btrfs_key *ins_keys;
 		u32 *ins_sizes;
 
-		ins_data = kmalloc(count * sizeof(u32) +
-				   count * sizeof(struct btrfs_key), GFP_NOFS);
+		ins_data = kmalloc_array(count, sizeof(u32) + sizeof(struct btrfs_key), GFP_NOFS);
 		if (!ins_data)
 			return -ENOMEM;
 
@@ -4826,8 +4825,7 @@ static noinline int copy_items(struct btrfs_trans_handle *trans,
 
 	src = src_path->nodes[0];
 
-	ins_data = kmalloc(nr * sizeof(struct btrfs_key) +
-			   nr * sizeof(u32), GFP_NOFS);
+	ins_data = kmalloc_array(nr, sizeof(struct btrfs_key) + sizeof(u32), GFP_NOFS);
 	if (!ins_data)
 		return -ENOMEM;
 
@@ -6532,8 +6530,7 @@ static int log_delayed_insertion_items(struct btrfs_trans_handle *trans,
 	if (!first)
 		return 0;
 
-	ins_data = kmalloc(max_batch_size * sizeof(u32) +
-			   max_batch_size * sizeof(struct btrfs_key), GFP_NOFS);
+	ins_data = kmalloc_array(max_batch_size, sizeof(u32) + sizeof(struct btrfs_key), GFP_NOFS);
 	if (!ins_data)
 		return -ENOMEM;
 	ins_sizes = (u32 *)ins_data;
-- 
2.51.0

On Fri, Sep 19, 2025 at 04:58:15PM +0200, Miquel Sabaté Solà wrote:
> As pointed out in the documentation, calling 'kmalloc' with open-coded
> arithmetic can lead to unfortunate overflows and this particular way of
> using it has been deprecated. Instead, it's preferred to use
> 'kmalloc_array' in cases where it might apply so an overflow check is
> performed.

So this is an API cleanup and it makes sense to use the checked
multiplication but it should be also said that this is not fixing any
overflow because in all cases the multipliers are bounded small numbers
derived from number of items in leaves/nodes.

> Signed-off-by: Miquel Sabaté Solà <mssola@mssola.com>

Reviewed-by: David Sterba <dsterba@suse.com>

Hello,

David Sterba @ 2025-09-22 12:28 +02:

> On Fri, Sep 19, 2025 at 04:58:15PM +0200, Miquel Sabaté Solà wrote:
>> As pointed out in the documentation, calling 'kmalloc' with open-coded
>> arithmetic can lead to unfortunate overflows and this particular way of
>> using it has been deprecated. Instead, it's preferred to use
>> 'kmalloc_array' in cases where it might apply so an overflow check is
>> performed.
>
> So this is an API cleanup and it makes sense to use the checked
> multiplication but it should be also said that this is not fixing any
> overflow because in all cases the multipliers are bounded small numbers
> derived from number of items in leaves/nodes.

Yes, it's just an API cleanup and I don't think it fixes any current bug
in the code base. So no need to CC stable or anything like that.

>
>> Signed-off-by: Miquel Sabaté Solà <mssola@mssola.com>
>
> Reviewed-by: David Sterba <dsterba@suse.com>

Thanks for the review!
Miquel

On Mon, Sep 22, 2025 at 02:47:13PM +0200, Miquel Sabaté Solà wrote:
> Hello,
> 
> David Sterba @ 2025-09-22 12:28 +02:
> 
> > On Fri, Sep 19, 2025 at 04:58:15PM +0200, Miquel Sabaté Solà wrote:
> >> As pointed out in the documentation, calling 'kmalloc' with open-coded
> >> arithmetic can lead to unfortunate overflows and this particular way of
> >> using it has been deprecated. Instead, it's preferred to use
> >> 'kmalloc_array' in cases where it might apply so an overflow check is
> >> performed.
> >
> > So this is an API cleanup and it makes sense to use the checked
> > multiplication but it should be also said that this is not fixing any
> > overflow because in all cases the multipliers are bounded small numbers
> > derived from number of items in leaves/nodes.
> 
> Yes, it's just an API cleanup and I don't think it fixes any current bug
> in the code base. So no need to CC stable or anything like that.

Still the changelog should say explicitly that it's not a bug fix before
somebody assigns a CVE to it because it mentions overflow.

David Sterba @ 2025-09-23 08:13 +02:

> On Mon, Sep 22, 2025 at 02:47:13PM +0200, Miquel Sabaté Solà wrote:
>> Hello,
>>
>> David Sterba @ 2025-09-22 12:28 +02:
>>
>> > On Fri, Sep 19, 2025 at 04:58:15PM +0200, Miquel Sabaté Solà wrote:
>> >> As pointed out in the documentation, calling 'kmalloc' with open-coded
>> >> arithmetic can lead to unfortunate overflows and this particular way of
>> >> using it has been deprecated. Instead, it's preferred to use
>> >> 'kmalloc_array' in cases where it might apply so an overflow check is
>> >> performed.
>> >
>> > So this is an API cleanup and it makes sense to use the checked
>> > multiplication but it should be also said that this is not fixing any
>> > overflow because in all cases the multipliers are bounded small numbers
>> > derived from number of items in leaves/nodes.
>>
>> Yes, it's just an API cleanup and I don't think it fixes any current bug
>> in the code base. So no need to CC stable or anything like that.
>
> Still the changelog should say explicitly that it's not a bug fix before
> somebody assigns a CVE to it because it mentions overflow.

Got it! I will submit a v2 and make this more explicit.

Thanks,
Miquel

On Tue, Sep 23, 2025 at 08:47:35AM +0200, Miquel Sabaté Solà wrote:
> David Sterba @ 2025-09-23 08:13 +02:
> 
> > On Mon, Sep 22, 2025 at 02:47:13PM +0200, Miquel Sabaté Solà wrote:
> >> Hello,
> >>
> >> David Sterba @ 2025-09-22 12:28 +02:
> >>
> >> > On Fri, Sep 19, 2025 at 04:58:15PM +0200, Miquel Sabaté Solà wrote:
> >> >> As pointed out in the documentation, calling 'kmalloc' with open-coded
> >> >> arithmetic can lead to unfortunate overflows and this particular way of
> >> >> using it has been deprecated. Instead, it's preferred to use
> >> >> 'kmalloc_array' in cases where it might apply so an overflow check is
> >> >> performed.
> >> >
> >> > So this is an API cleanup and it makes sense to use the checked
> >> > multiplication but it should be also said that this is not fixing any
> >> > overflow because in all cases the multipliers are bounded small numbers
> >> > derived from number of items in leaves/nodes.
> >>
> >> Yes, it's just an API cleanup and I don't think it fixes any current bug
> >> in the code base. So no need to CC stable or anything like that.
> >
> > Still the changelog should say explicitly that it's not a bug fix before
> > somebody assigns a CVE to it because it mentions overflow.
> 
> Got it! I will submit a v2 and make this more explicit.

No need to, I've updated the changelog at commit time.

David Sterba @ 2025-09-23 09:00 +02:

> On Tue, Sep 23, 2025 at 08:47:35AM +0200, Miquel Sabaté Solà wrote:
>> David Sterba @ 2025-09-23 08:13 +02:
>>
>> > On Mon, Sep 22, 2025 at 02:47:13PM +0200, Miquel Sabaté Solà wrote:
>> >> Hello,
>> >>
>> >> David Sterba @ 2025-09-22 12:28 +02:
>> >>
>> >> > On Fri, Sep 19, 2025 at 04:58:15PM +0200, Miquel Sabaté Solà wrote:
>> >> >> As pointed out in the documentation, calling 'kmalloc' with open-coded
>> >> >> arithmetic can lead to unfortunate overflows and this particular way of
>> >> >> using it has been deprecated. Instead, it's preferred to use
>> >> >> 'kmalloc_array' in cases where it might apply so an overflow check is
>> >> >> performed.
>> >> >
>> >> > So this is an API cleanup and it makes sense to use the checked
>> >> > multiplication but it should be also said that this is not fixing any
>> >> > overflow because in all cases the multipliers are bounded small numbers
>> >> > derived from number of items in leaves/nodes.
>> >>
>> >> Yes, it's just an API cleanup and I don't think it fixes any current bug
>> >> in the code base. So no need to CC stable or anything like that.
>> >
>> > Still the changelog should say explicitly that it's not a bug fix before
>> > somebody assigns a CVE to it because it mentions overflow.
>>
>> Got it! I will submit a v2 and make this more explicit.
>
> No need to, I've updated the changelog at commit time.

Ah, then ignore the v2 patch set I've just sent, which simply changes
the commit log as you suggested.