Re: [PATCH] remoteproc: imx_rproc: allow mappings ending at region boundary

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Missing overflow checks on `da + len` and `sys + len` allow a maliciously crafted ELF segment to bypass bounds validation, resulting in massive out-of-bounds kernel memory corruption.
--

commit d94c3c742cf1fcf451629ba1a51b1c180a0e9a41
Author: Marcel Hofmann <marcel.hofmann@ingenics-digital.com>

remoteproc: imx_rproc: allow mappings ending at region boundary

This commit updates the address bounds checking in imx_rproc_da_to_sys() and
imx_rproc_da_to_va() to include the exact region boundary. It allows ELF
segments that perfectly fill a mapped memory region to load successfully.

> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 745ce52cd8226..f3c7c2ff6713c 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 in imx_rproc_da_to_sys() does this bounds
check evaluate da + len without guarding against 64-bit integer overflow?

If a maliciously crafted ELF file provides a segment with a massive p_memsz,
could da + len wrap around to a small value? This might satisfy both
da >= att->da and da + len <= att->da + att->size, bypassing the bounds
validation and potentially causing a massive out-of-bounds memset() in kernel
memory during ELF loading.

[ ... ]

> @@ -585,7 +585,7 @@ static void *imx_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *i
>  		return NULL;
>  
>  	for (i = 0; i < IMX_RPROC_MEM_MAX; i++) {
> -		if (sys >= priv->mem[i].sys_addr && sys + len <
> +		if (sys >= priv->mem[i].sys_addr && sys + len <=
>  		    priv->mem[i].sys_addr +  priv->mem[i].size) {

[Severity: High]
This is also a pre-existing issue, but in imx_rproc_da_to_va() does this
secondary check similarly fail to catch the overflow?

Could the sys + len addition allow the bypassed bounds to be translated into
a valid kernel virtual address for the massive segment?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260826153838.19018-1-marcel@hofmania.de?part=1