Re: [PATCH v3] ARM: imx: Fix suspend/resume crash with Clang CFI

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Critical] W^X Violation / Exploit Mitigation Bypass via Writable OCRAM Alias
--

--- Patch [1]: [PATCH v3] ARM: imx: Fix suspend/resume crash with Clang CFI ---
commit b6dc32274a7f40075998a9c67f552a3982169e81
Author: Yo'av Moshe <linux@yoavmoshe.com>

ARM: imx: Fix suspend/resume crash with Clang CFI

This commit fixes a suspend/resume crash caused by CFI violations on indirect 
calls to relocated OCRAM code. It introduces a minimal __nocfi wrapper for 
the OCRAM call and marks relevant pointers as __ro_after_init to mitigate 
potential exploit risks.

> diff --git a/arch/arm/mach-imx/pm-imx6.c b/arch/arm/mach-imx/pm-imx6.c
> index a671ca498f887..3d5b960c583bd 100644
> --- a/arch/arm/mach-imx/pm-imx6.c
> +++ b/arch/arm/mach-imx/pm-imx6.c
> @@ -61,9 +61,9 @@
>  #define MX6Q_SUSPEND_OCRAM_SIZE		0x1000
>  #define MX6_MAX_MMDC_IO_NUM		33
>  
> -static void __iomem *ccm_base;
> -static void __iomem *suspend_ocram_base;
> -static void (*imx6_suspend_in_ocram_fn)(void __iomem *ocram_vbase);
> +static void __iomem *ccm_base __ro_after_init;
> +static void __iomem *suspend_ocram_base __ro_after_init;
> +static void (*imx6_suspend_in_ocram_fn)(void __iomem *ocram_vbase) __ro_after_init;

[ ... ]

> @@ -360,6 +360,11 @@ int imx6_set_lpm(enum mxc_cpu_pwr_mode mode)
>  	return 0;
>  }
>  
> +static void __nocfi imx6_suspend_in_ocram(void __iomem *ocram_vbase)
> +{
> +	imx6_suspend_in_ocram_fn(ocram_vbase);
> +}

[Severity: Critical]
This is a pre-existing issue, but does adding __ro_after_init fully protect 
this memory from write-what-where attacks?

Looking at imx6q_suspend_init(), physical OCRAM memory is mapped with both a 
persistent writable alias (ocram_base) and an executable alias 
(suspend_ocram_base):

arch/arm/mach-imx/pm-imx6.c:imx6q_suspend_init() {
    ocram_base = gen_pool_alloc(ocram_pool, MX6Q_SUSPEND_OCRAM_SIZE);
    ...
    ocram_pbase = gen_pool_virt_to_phys(ocram_pool, ocram_base);

    suspend_ocram_base = __arm_ioremap_exec(ocram_pbase,
        MX6Q_SUSPEND_OCRAM_SIZE, false);
    ...
    __arm_iomem_set_ro(suspend_ocram_base, MX6Q_SUSPEND_OCRAM_SIZE);
}

Even though suspend_ocram_base is marked read-only and its pointer is now 
__ro_after_init, the initial writable alias (ocram_base) appears to remain 
fully active without being unmapped.

Since this patch introduces a __nocfi wrapper to execute this memory, could an 
attacker still bypass CFI by writing shellcode directly into the active 
writable ocram_base alias?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260718111340.159896-1-linux@yoavmoshe.com?part=1