From: sashiko-bot@kernel.org
To: "Dawid Osuchowski" <dawid.osuchowski@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 3/3] accel/ivpu: Limit firmware log name prints to field size
Date: Tue, 01 Sep 2026 13:19:06 +0000 [thread overview]
Message-ID: <20260901131906.BC9581F00A3E@smtp.kernel.org> (raw)
In-Reply-To: <20260901125749.404338-4-dawid.osuchowski@linux.intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Unbounded string read from firmware data in `ivpu_fw_parse`.
--
commit 7d0d9c625b89d41a9d3cbe859e6e2b33348102cf
Author: Dawid Osuchowski <dawid.osuchowski@linux.intel.com>
accel/ivpu: Limit firmware log name prints to field size
This patch fixes an issue where the NPU firmware log name field is printed
using an unbounded string conversion. By enforcing a precision limit based
on the field's size, it prevents out-of-bounds memory reads if the firmware
string is missing its NUL terminator.
Closes: https://sashiko.dev/#/patchset/20260827102339.281799-1-dawid.osuchowski@linux.intel.com?part=2
> diff --git a/drivers/accel/ivpu/ivpu_fw_log.c b/drivers/accel/ivpu/ivpu_fw_log.c
> index 4f9055aa9d33f..9eafc42120b6a 100644
> --- a/drivers/accel/ivpu/ivpu_fw_log.c
> +++ b/drivers/accel/ivpu/ivpu_fw_log.c
> @@ -69,9 +69,9 @@ static int fw_log_from_bo(struct ivpu_device *vdev, struct ivpu_bo *bo, u32 *off
> *offset += size;
>
> ivpu_dbg(vdev, FW_BOOT,
> - "FW log name \"%s\", write offset 0x%x size 0x%x, wrap count %d, hdr version %d size %d format %d, alignment %d",
> - log->name, log->write_index, size, log->wrap_count, log->header_version,
> - header_size, log->format, log->alignment);
> + "FW log name \"%.*s\", write offset 0x%x size 0x%x, wrap count %d, hdr version %d size %d format %d, alignment %d",
> + (int)ARRAY_SIZE(log->name), log->name, log->write_index, size, log->wrap_count,
> + log->header_version, header_size, log->format, log->alignment);
[Severity: High]
This isn't a bug introduced by this patch, but since this patch fixes an
unbounded string read, is there a similar issue in ivpu_fw_parse() when
reading the firmware version?
Looking at drivers/accel/ivpu/ivpu_fw.c:ivpu_fw_parse():
if (!scnprintf(fw->version, sizeof(fw->version), "%s", fw->file->data + VPU_FW_HEADER_SIZE))
ivpu_warn(vdev, "Missing firmware version\n");
The scnprintf() function evaluates the length of the source string until a NUL
byte is found when no precision is provided for "%s", regardless of the
destination buffer size.
If the loaded firmware file lacks a NUL terminator at VPU_FW_HEADER_SIZE,
could this lead to an out-of-bounds read past the loaded firmware data?
This could trigger a page fault and expose adjacent kernel memory if a
malformed firmware file is supplied.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260901125749.404338-1-dawid.osuchowski@linux.intel.com?part=3
next prev parent reply other threads:[~2026-09-01 13:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 12:57 [PATCH v2 0/3] accel/ivpu: Harden parsing of firmware-shared buffers Dawid Osuchowski
2026-09-01 12:57 ` [PATCH v2 1/3] accel/ivpu: Validate full buffer range in ivpu_to_cpu_addr Dawid Osuchowski
2026-09-02 12:56 ` Wachowski, Karol
2026-09-01 12:57 ` [PATCH v2 2/3] accel/ivpu: Validate firmware log buffer metadata Dawid Osuchowski
2026-09-02 12:57 ` Wachowski, Karol
2026-09-01 12:57 ` [PATCH v2 3/3] accel/ivpu: Limit firmware log name prints to field size Dawid Osuchowski
2026-09-01 13:19 ` sashiko-bot [this message]
2026-09-02 12:58 ` Wachowski, Karol
2026-09-07 6:13 ` [PATCH v2 0/3] accel/ivpu: Harden parsing of firmware-shared buffers Wachowski, Karol
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=20260901131906.BC9581F00A3E@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dawid.osuchowski@linux.intel.com \
--cc=dri-devel@lists.freedesktop.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.