[PATCH] remoteproc: imx_rproc: Fix off-by-one in address translation

[PATCH] remoteproc: imx_rproc: Fix off-by-one in address translation

[Peng Fan (OSS)]

From: Peng Fan <peng.fan@nxp.com>

In imx_rproc_da_to_sys(), a firmware segment that exactly fills the
remainder of a memory region (da + len == att->da + att->size) is
wrongly rejected due to a strict less-than comparison. Use <= to
accept this valid boundary case.

Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260729013506.584321F000E9@smtp.kernel.org/
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 drivers/remoteproc/imx_rproc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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) {
 			unsigned int offset = da - att->da;
 
 			*sys = att->sa + offset;

---
base-commit: 3652b49adac266a3d27cb41cdfdb7d8790fc3633
change-id: 20260729-imx-rproc-range-6383734aff49

Best regards,
--  
Peng Fan <peng.fan@nxp.com>

Re: [PATCH] remoteproc: imx_rproc: Fix off-by-one in address translation

[sashiko-bot]

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

RE: [PATCH] remoteproc: imx_rproc: Fix off-by-one in address translation

[Peng Fan]

> Subject: [PATCH] remoteproc: imx_rproc: Fix off-by-one in address
> translation

Ignore this patch. The fix is not complete.

Thanks,
Peng.

> 
> From: Peng Fan <peng.fan@nxp.com>
> 
> In imx_rproc_da_to_sys(), a firmware segment that exactly fills the
> remainder of a memory region (da + len == att->da + att->size) is
> wrongly rejected due to a strict less-than comparison. Use <= to accept
> this valid boundary case.
> 
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Closes:
> https://lore.kernel.org/all/20260729013506.584321F000E9@smtp.ker
> nel.org/
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
>  drivers/remoteproc/imx_rproc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> 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) {
>  			unsigned int offset = da - att->da;
> 
>  			*sys = att->sa + offset;
> 
> ---
> base-commit: 3652b49adac266a3d27cb41cdfdb7d8790fc3633
> change-id: 20260729-imx-rproc-range-6383734aff49
> 
> Best regards,
> --
> Peng Fan <peng.fan@nxp.com>