* [PATCH] remoteproc: imx_rproc: allow mappings ending at region boundary
@ 2026-08-26 15:38 Marcel Hofmann
2026-08-26 15:51 ` sashiko-bot
0 siblings, 1 reply; 2+ messages in thread
From: Marcel Hofmann @ 2026-08-26 15:38 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier
Cc: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Oleksij Rempel, linux-remoteproc, imx, linux-arm-kernel,
linux-kernel, Marcel Hofmann
From: Marcel Hofmann <marcel.hofmann@ingenics-digital.com>
The address range checks in imx_rproc_da_to_sys() and
imx_rproc_da_to_va() use a strict comparison for the exclusive end
address of the requested range.
As a result, a valid request that ends exactly at the end of an address
translation or mapped memory region is rejected. For a region
[start, start + size), a request [addr, addr + len) is contained when:
addr >= start && addr + len <= start + size
This occurs when a loadable ELF segment fills an entire mapped memory
region. This can be produced by a linker script that extends the
resource table section to the end of its designated region:
.resource_table :
{
. = ALIGN(8);
KEEP(*(.resource_table)) /* Resource table */
. = ALIGN(8);
. = ORIGIN(m_rsc_tbl) + LENGTH(m_rsc_tbl);
} > m_rsc_tbl =0x00
This produces a ELF program header like:
LOAD 0x010000 0xa4220000 0xa4220000 0x01000 0x01000 R 0x1000
In this case, the segment size matches the mapped region size exactly,
causing the address translation to fail with:
bad phdr da 0xa4220000 mem 0x1000
Use <= for the upper-bound checks so that ranges ending exactly at the
region boundary are accepted.
Fixes: a0ff4aa6f010 ("remoteproc: imx_rproc: add a NXP/Freescale imx_rproc driver")
Signed-off-by: Marcel Hofmann <marcel.hofmann@ingenics-digital.com>
---
drivers/remoteproc/imx_rproc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 745ce52cd822..f3c7c2ff6713 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;
@@ -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) {
unsigned int offset = sys - priv->mem[i].sys_addr;
/* __force to make sparse happy with type conversion */
base-commit: bb840ea69347aff7bde5a208e7b5b180669a7656
--
2.43.0
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH] remoteproc: imx_rproc: allow mappings ending at region boundary
2026-08-26 15:38 [PATCH] remoteproc: imx_rproc: allow mappings ending at region boundary Marcel Hofmann
@ 2026-08-26 15:51 ` sashiko-bot
0 siblings, 0 replies; 2+ messages in thread
From: sashiko-bot @ 2026-08-26 15:51 UTC (permalink / raw)
To: Marcel Hofmann; +Cc: Frank.Li, imx
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-08-26 15:51 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-26 15:38 [PATCH] remoteproc: imx_rproc: allow mappings ending at region boundary Marcel Hofmann
2026-08-26 15:51 ` sashiko-bot
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox