All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Mikko Perttunen" <mperttunen@nvidia.com>
Cc: devicetree@vger.kernel.org, robh@kernel.org,
	dri-devel@lists.freedesktop.org, conor+dt@kernel.org
Subject: Re: [PATCH v2 5/7] drm/tegra: falcon: Add support for RISC-V external boot
Date: Mon, 22 Jun 2026 07:08:39 +0000	[thread overview]
Message-ID: <20260622070840.567391F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260622-t264-host1x-v2-5-ff7364d9ff7b@nvidia.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing bounds check, endianness conversion, and size validation of the RISC-V firmware descriptor leads to out-of-bounds memory accesses and unbounded DMA.
--

commit ce83e1285215f11b260dbf628363fe352ce09b78
Author: Mikko Perttunen <mperttunen@nvidia.com>

drm/tegra: falcon: Add support for RISC-V external boot

Add support for loading and booting RISC-V firmwares on Falcons with
RISC-V hardware.

> diff --git a/drivers/gpu/drm/tegra/falcon.c b/drivers/gpu/drm/tegra/falcon.c
> index 17f616bbcb45b..1172356b6af3b 100644
> --- a/drivers/gpu/drm/tegra/falcon.c
> +++ b/drivers/gpu/drm/tegra/falcon.c

[ ... ]

> @@ -122,6 +126,17 @@ static int falcon_parse_firmware_image(struct falcon *falcon)
>  	return 0;
>  }
>  
> +static void falcon_parse_firmware_desc(struct falcon *falcon)
> +{
> +	struct falcon_fw_riscv_desc *desc =
> +		(struct falcon_fw_riscv_desc *)falcon->firmware.desc_firmware->data;
> +
> +	falcon->firmware.code.offset = desc->code_offset;
> +	falcon->firmware.code.size = desc->code_size;
> +	falcon->firmware.data.offset = desc->data_offset;
> +	falcon->firmware.data.size = desc->data_size;

[Severity: High]
Does this code need to validate the size of desc_firmware before casting its
data to struct falcon_fw_riscv_desc? If the firmware file is smaller than the
struct size, this could lead to an out-of-bounds read.

Also, do these fields need le32_to_cpu() conversion for big-endian systems,
similar to how the main firmware is handled in falcon_copy_firmware_image()?

Finally, are the parsed sizes and offsets validated against the main firmware's
size? If not, these unchecked values could cause out-of-bounds host memory
accesses later in falcon_boot() when they are used in the falcon_copy_chunk()
DMA loops:

    for (offset = 0; offset < falcon->firmware.data.size; offset += 256)
        falcon_copy_chunk(falcon,
                          falcon->firmware.data.offset + offset,
                          offset, FALCON_MEMORY_DATA);

> +}
> +
>  int falcon_read_firmware(struct falcon *falcon, const char *name)
>  {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260622-t264-host1x-v2-0-ff7364d9ff7b@nvidia.com?part=5

  reply	other threads:[~2026-06-22  7:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-22  6:57 [PATCH v2 0/7] Host1x/VIC support on Tegra264 Mikko Perttunen
2026-06-22  6:57 ` [PATCH v2 1/7] dt-bindings: display: tegra: Changes to support Tegra264 Mikko Perttunen
2026-06-22  6:57 ` [PATCH v2 2/7] dt-bindings: display: tegra: Add Tegra264 compatible for VIC Mikko Perttunen
2026-06-22  6:57 ` [PATCH v2 3/7] gpu: host1x: Correctly parse linear ranges of context devices Mikko Perttunen
2026-06-22  7:09   ` sashiko-bot
2026-06-22  6:57 ` [PATCH v2 4/7] gpu: host1x: Add Tegra264 support Mikko Perttunen
2026-06-22  7:05   ` sashiko-bot
2026-06-22  6:57 ` [PATCH v2 5/7] drm/tegra: falcon: Add support for RISC-V external boot Mikko Perttunen
2026-06-22  7:08   ` sashiko-bot [this message]
2026-06-22  6:57 ` [PATCH v2 6/7] drm/tegra: vic: Add Tegra264 support Mikko Perttunen
2026-06-22  7:11   ` sashiko-bot
2026-06-22  6:57 ` [PATCH v2 7/7] arm64: tegra: Add Host1x and VIC on Tegra264 Mikko Perttunen

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=20260622070840.567391F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=mperttunen@nvidia.com \
    --cc=robh@kernel.org \
    --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.