All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Ben Levinsky" <ben.levinsky@amd.com>
Cc: imx@lists.linux.dev, wsa+renesas@sang-engineering.com,
	Frank.Li@kernel.org
Subject: Re: [PATCH v2 5/5] remoteproc: switch drivers to optional resource-table helper
Date: Thu, 14 May 2026 22:14:55 +0000	[thread overview]
Message-ID: <20260514221455.A97F1C2BCB3@smtp.kernel.org> (raw)
In-Reply-To: <20260514162129.1504162-6-ben.levinsky@amd.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] This problem wasn't introduced by this patch, but an integer overflow in ELF segment bounds checking in `imx_dsp_rproc_elf_load_segments()` allows an attacker to bypass validations and perform an out-of-bounds read. `offset` and `filesz` are 64-bit values (`u64`) parsed directly from ELF program headers. The boundary check `if (offset + filesz > fw->size)` lacks protection against integer overflow. A malicious or corrupted firmware can supply a massive `offset` (e.g., 0xFFFFFFFFFFFFFFFE) and a small `filesz` (e.g., 0x10), causing `offset + filesz` to wrap around to a small integer (0x0E). This bypasses the `> fw->size` check. The code then executes `imx_dsp_rproc_memcpy(ptr, elf_data + offset, filesz);`, where pointer arithmetic on `elf_data + offset` resolves outside the firmware buffer, resulting in an out-of-bounds read that leaks kernel memory or causes a kernel panic.
--

commit 71c8dfba5336b57c340ad4c8970a2211c5b78f4f
Author: Ben Levinsky <ben.levinsky@amd.com>

remoteproc: switch drivers to optional resource-table helper

This commit switches several remoteproc drivers to use the shared optional
resource-table helper for firmware that treats a missing resource table as
non-fatal. It retains local parse_fw() wrappers to manage return-value
logging and severity.

> diff --git a/drivers/remoteproc/imx_dsp_rproc.c b/drivers/remoteproc/imx_dsp_rproc.c
> index 2d9f14fbef1da..2ff74f7938f61 100644
> --- a/drivers/remoteproc/imx_dsp_rproc.c
> +++ b/drivers/remoteproc/imx_dsp_rproc.c
> @@ -954,14 +954,6 @@ static int imx_dsp_rproc_elf_load_segments(struct rproc *rproc, const struct fir
>  	return ret;
>  }

This problem wasn't introduced by this patch, but while reviewing
imx_dsp_rproc_elf_load_segments(), I noticed a potential integer overflow
in the ELF segment bounds checking.

Since offset and filesz are 64-bit values (u64) parsed directly from the
ELF program headers, does this code overflow offset + filesz?

drivers/remoteproc/imx_dsp_rproc.c:imx_dsp_rproc_elf_load_segments() {
        ...
        if (offset + filesz > fw->size) {
                dev_err(dev, "truncated fw: need 0x%llx avail 0x%zx\n",
                        offset + filesz, fw->size);
                ret = -EINVAL;
                break;
        }
        ...
        if (filesz) {
                ret = imx_dsp_rproc_memcpy(ptr, elf_data + offset, filesz);
        ...
}

A malicious or corrupted firmware could supply a massive offset
(e.g., 0xFFFFFFFFFFFFFFFE) and a small filesz (e.g., 0x10).
This would cause offset + filesz to wrap around to a small integer (0x0E),
bypassing the bounds check.

Could this lead to pointer arithmetic on elf_data + offset resolving
outside the firmware buffer, resulting in an out-of-bounds read during
the memcpy?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260514162129.1504162-1-ben.levinsky@amd.com?part=5

      reply	other threads:[~2026-05-14 22:14 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-14 16:21 [PATCH v2 0/5] remoteproc: cleanup shared carveout and resource-table helpers Ben Levinsky
2026-05-14 16:21 ` [PATCH v2 1/5] remoteproc: add common wc-ioremap carveout callbacks Ben Levinsky
2026-05-14 16:21 ` [PATCH v2 2/5] remoteproc: switch exact-match drivers to wc-ioremap callbacks Ben Levinsky
2026-05-14 21:00   ` sashiko-bot
2026-05-14 16:21 ` [PATCH v2 3/5] remoteproc: mark wc-ioremap carveouts as iomem Ben Levinsky
2026-05-14 21:48   ` sashiko-bot
2026-05-14 16:21 ` [PATCH v2 4/5] remoteproc: add helper for optional ELF resource tables Ben Levinsky
2026-05-14 16:21 ` [PATCH v2 5/5] remoteproc: switch drivers to optional resource-table helper Ben Levinsky
2026-05-14 22:14   ` sashiko-bot [this message]

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=20260514221455.A97F1C2BCB3@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=ben.levinsky@amd.com \
    --cc=imx@lists.linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=wsa+renesas@sang-engineering.com \
    /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.