From: sashiko-bot@kernel.org
To: "Andrew Soto" <linux@notrealandy.dev>
Cc: linux-media@vger.kernel.org
Subject: Re: [PATCH] staging: media: atomisp: prefer kcalloc over kzalloc with multiply
Date: Sat, 06 Jun 2026 23:57:21 +0000 [thread overview]
Message-ID: <20260606235721.87D501F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260606234427.9902-1-linux@notrealandy.dev>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Ignored memory allocation failure leads to null-equivalent pointer passed to SP firmware.
--
commit 967be0a2dfa51f2c0edc88c4aa3976bc41aab85d
Author: Andrew Soto <linux@notrealandy.dev>
staging: media: atomisp: prefer kcalloc over kzalloc with multiply
This commit replaces a raw multiplication inside kzalloc() with a kcalloc()
array allocation in sh_css_params.c. This validates the array size
calculations to prevent potential integer overflow vulnerabilities before
interacting with the kernel heap allocator.
> diff --git a/drivers/staging/media/atomisp/pci/sh_css_params.c b/drivers/staging/media/atomisp/pci/sh_css_params.c
> index fcebace11daf6..9147ca0474ad2 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;
[Severity: High]
This isn't a bug introduced by this patch, but is it possible that this early
return causes the firmware to crash under memory pressure?
If kcalloc() fails, sh_css_store_sp_group_to_ddr() returns 0, which acts as
a null-equivalent for an ia_css_ptr.
Looking at the caller in drivers/staging/media/atomisp/pci/sh_css_sp.c:
store_sp_group_data() {
...
per_frame_data.sp_group_addr = sh_css_store_sp_group_to_ddr();
...
}
The return value is unconditionally assigned to per_frame_data.sp_group_addr
without any validation. When this 0 is sent directly to the per-frame
hardware configuration, will the SP firmware crash or lock up the hardware
when attempting to access address 0 for its group configuration?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260606234427.9902-1-linux@notrealandy.dev?part=1
next prev parent reply other threads:[~2026-06-06 23:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-06 23:44 [PATCH] staging: media: atomisp: prefer kcalloc over kzalloc with multiply Andrew Soto
2026-06-06 23:57 ` sashiko-bot [this message]
2026-06-07 7:42 ` Andy Shevchenko
[not found] ` <B7B15655-45FE-4538-87A5-9D0926E8A941@notrealandy.dev>
[not found] ` <CAHp75VdjTSjqana9kCoE9mL+UkKcu-x_bPHP9asjkm4sWQTKUg@mail.gmail.com>
2026-06-07 18:51 ` Fwd: " Andy Shevchenko
2026-06-07 12:18 ` [PATCH v2] " Andrew Soto
2026-06-07 18:52 ` Andy Shevchenko
2026-06-08 7:08 ` [PATCH] " Dan Carpenter
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=20260606235721.87D501F00893@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux@notrealandy.dev \
--cc=sashiko-reviews@lists.linux.dev \
/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.