[PATCH] staging: media: atomisp: prefer kcalloc over kzalloc with multiply

Andrew Soto posted 1 patch 1 day, 4 hours ago
There is a newer version of this series
drivers/staging/media/atomisp/pci/sh_css_params.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
[PATCH] staging: media: atomisp: prefer kcalloc over kzalloc with multiply
Posted by Andrew Soto 1 day, 4 hours ago
Optimize memory allocation layout in sh_css_params.c by replacing the raw multiplication inside kzalloc() with a type-safe kcalloc() array allocation wrapper.

This prevents potential integer overflow vulnerabilities by validating the array size calculations before interacting with the kernel heap allocator, aligning the driver with modern kernel memory allocation standards.

Signed-off-by: Andrew Soto <linux@notrealandy.dev>
---
 drivers/staging/media/atomisp/pci/sh_css_params.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/pci/sh_css_params.c b/drivers/staging/media/atomisp/pci/sh_css_params.c
index fcebace11..9147ca047 100644
--- a/drivers/staging/media/atomisp/pci/sh_css_params.c
+++ b/drivers/staging/media/atomisp/pci/sh_css_params.c
@@ -3716,7 +3716,7 @@ ia_css_ptr sh_css_store_sp_group_to_ddr(void)
 
 	IA_CSS_ENTER_LEAVE_PRIVATE("void");
 
-	write_buf = kzalloc(sizeof(u8) * 8192, GFP_KERNEL);
+	write_buf = kcalloc(8192, sizeof(u8), GFP_KERNEL);
 	if (!write_buf)
 		return 0;
 
-- 
2.53.0
Re: [PATCH] staging: media: atomisp: prefer kcalloc over kzalloc with multiply
Posted by Andy Shevchenko 20 hours ago
On Sun, Jun 7, 2026 at 2:45 AM Andrew Soto <linux@notrealandy.dev> wrote:
>
> Optimize memory allocation layout in sh_css_params.c by replacing the raw multiplication inside kzalloc() with a type-safe kcalloc() array allocation wrapper.
>
> This prevents potential integer overflow vulnerabilities by validating the array size calculations before interacting with the kernel heap allocator, aligning the driver with modern kernel memory allocation standards.

Wrap the commit message around 72 characters per line.

...

Is this the only case like this in the entire driver?

-- 
With Best Regards,
Andy Shevchenko
[PATCH v2] staging: media: atomisp: prefer kcalloc over kzalloc with multiply
Posted by Andrew Soto 16 hours ago
Optimize memory allocation layout in sh_css_params.c by replacing
the raw multiplication inside kzalloc() with a type-safe kcalloc()
array allocation wrapper.

This prevents potential integer overflow vulnerabilities by validating
the array size calculations before interacting
with the kernel heap allocator, aligning the driver with modern kernel
memory allocation standards.

Signed-off-by: Andrew Soto <linux@notrealandy.dev>
---
 drivers/staging/media/atomisp/pci/sh_css_params.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/pci/sh_css_params.c b/drivers/staging/media/atomisp/pci/sh_css_params.c
index fcebace11..9147ca047 100644
--- a/drivers/staging/media/atomisp/pci/sh_css_params.c
+++ b/drivers/staging/media/atomisp/pci/sh_css_params.c
@@ -3716,7 +3716,7 @@ ia_css_ptr sh_css_store_sp_group_to_ddr(void)
 
 	IA_CSS_ENTER_LEAVE_PRIVATE("void");
 
-	write_buf = kzalloc(sizeof(u8) * 8192, GFP_KERNEL);
+	write_buf = kcalloc(8192, sizeof(u8), GFP_KERNEL);
 	if (!write_buf)
 		return 0;
 
-- 
2.53.0
Re: [PATCH v2] staging: media: atomisp: prefer kcalloc over kzalloc with multiply
Posted by Andy Shevchenko 9 hours ago
On Sun, Jun 7, 2026 at 3:19 PM Andrew Soto <linux@notrealandy.dev> wrote:
>
> Optimize memory allocation layout in sh_css_params.c by replacing
> the raw multiplication inside kzalloc() with a type-safe kcalloc()
> array allocation wrapper.
>
> This prevents potential integer overflow vulnerabilities by validating
> the array size calculations before interacting
> with the kernel heap allocator, aligning the driver with modern kernel
> memory allocation standards.

See my reply to v1.

...

> -       write_buf = kzalloc(sizeof(u8) * 8192, GFP_KERNEL);
> +       write_buf = kcalloc(8192, sizeof(u8), GFP_KERNEL);

While at it, you can switch to a more robust sizeof(*write_buf).

-- 
With Best Regards,
Andy Shevchenko