Linux kernel and device drivers for NXP i.MX platforms
 help / color / mirror / Atom feed
* [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