All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Peng Fan (OSS)" <peng.fan@oss.nxp.com>
Cc: imx@lists.linux.dev, Frank.Li@kernel.org
Subject: Re: [PATCH] remoteproc: imx_rproc: Fix off-by-one in address translation
Date: Thu, 30 Jul 2026 03:21:06 +0000	[thread overview]
Message-ID: <20260730032107.0D7F91F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260730-imx-rproc-range-v1-1-97c9ca7a5658@nxp.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] The patch fixes an off-by-one boundary check in `imx_rproc_da_to_sys()` using `<=` but misses the identical boundary check in its caller `imx_rproc_da_to_va()`, leaving the bug unresolved.
- [High] An integer overflow in the memory segment bounds checks allows untrusted firmware to perform arbitrary out-of-bounds kernel writes on 64-bit platforms.
--

--- Patch [1]: [PATCH] remoteproc: imx_rproc: Fix off-by-one in address translation ---
commit 26c9a9508d8034f3f59181045a1d03a59fa5b603
Author: Peng Fan <peng.fan@nxp.com>

remoteproc: imx_rproc: Fix off-by-one in address translation

This commit fixes an off-by-one error in imx_rproc_da_to_sys() by changing a
strict less-than comparison to a less-than-or-equal comparison for firmware
segments that exactly fill a memory region.

Link: https://lore.kernel.org/all/20260729013506.584321F000E9@smtp.kernel.org/

> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 745ce52cd8226..9af0aa26ce9b7 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -552,7 +552,7 @@ static int imx_rproc_da_to_sys(struct imx_rproc *priv, u64 da,
>  				continue;
>  		}
>  
> -		if (da >= att->da && da + len < att->da + att->size) {
> +		if (da >= att->da && da + len <= att->da + att->size) {

[Severity: High]
This is a pre-existing issue, but does this fix actually solve the problem
since the caller still uses a strict less-than check?

When imx_rproc_da_to_sys() successfully translates a valid boundary case
where da + len == att->da + att->size, its caller imx_rproc_da_to_va() performs
a secondary boundary check:

drivers/remoteproc/imx_rproc.c:imx_rproc_da_to_va() {
    ...
    if (imx_rproc_da_to_sys(priv, da, len, &sys, is_iomem))
        return NULL;

    for (i = 0; i < IMX_RPROC_MEM_MAX; i++) {
        if (sys >= priv->mem[i].sys_addr && sys + len <
            priv->mem[i].sys_addr +  priv->mem[i].size) {
            ...
        }
    }
    ...
}

Because imx_rproc_da_to_va() still uses a strict less-than comparison (<)
instead of (<=), won't it still reject the exactly matching segment and
return NULL, preventing the system from booting valid firmware?


[Severity: High]
This is also a pre-existing issue, but can the da + len calculation overflow
64-bit integers on 64-bit platforms?

In rproc_elf_load_segments() from drivers/remoteproc/remoteproc_elf_loader.c,
da and memsz (len) are extracted from the ELF headers. By providing a
maliciously crafted da (e.g., 0x10000000) and a massive memsz
(e.g., 0xFFFFFFFFF0000000), da + len can overflow and wrap around to a small
value (e.g., 0).

Could this bypass the primary bounds check here:

    if (da >= att->da && da + len <= att->da + att->size) {

and the secondary check in imx_rproc_da_to_va():

    if (sys >= priv->mem[i].sys_addr && sys + len < ...

allowing untrusted firmware to perform arbitrary out-of-bounds kernel memory
writes during memcpy() in rproc_elf_load_segments()?

>  			unsigned int offset = da - att->da;
>  
>  			*sys = att->sa + offset;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260730-imx-rproc-range-v1-1-97c9ca7a5658@nxp.com?part=1

  reply	other threads:[~2026-07-30  3:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-30  3:12 [PATCH] remoteproc: imx_rproc: Fix off-by-one in address translation Peng Fan (OSS)
2026-07-30  3:21 ` sashiko-bot [this message]
2026-07-30  3:25 ` Peng Fan

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=20260730032107.0D7F91F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=imx@lists.linux.dev \
    --cc=peng.fan@oss.nxp.com \
    --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.