Re: [PATCH] mm/execmem: check execmem_restore_rox() failure in execmem_cache_free()

[Mike Rapoport <rppt@kernel.org>]

On Sun, Nov 15, 2026 at 12:47:04AM +0800, shao.mingyin@zte.com.cn wrote:
> From: Shao Mingyin <shao.mingyin@zte.com.cn>
> 
> mm/execmem: check execmem_restore_rox() failure in execmem_cache_free()
> 
> __execmem_cache_free() checks execmem_force_rw(), but ignores the
> matching execmem_restore_rox() result before adding the block to the
> free ROX cache. A failed restore can leave permissions only partially
> updated, so a later cache allocation can return memory that is not ROX.
> The cache allocation path does not reapply permissions.
> 
> Check the restore result and return the error. The existing callers keep
> failed frees pending and retry them through delayed work. This prevents
> a block whose ROX restoration failed from entering the free cache, and
> matches the error handling in execmem_vmalloc_rox().
> 
> Fixes: 187fd8521dd8 ("execmem: rework execmem_cache_free()")
> Cc: stable@vger.kernel.org # 6.17
> Signed-off-by: Shao Mingyin <shao.mingyin@zte.com.cn>
> ---
> Build-tested mm/execmem.o with W=1 and CONFIG_ARCH_HAS_EXECMEM_ROX=y
> on x86_64. The pending-free error path was reviewed statically.
> No natural CPA restore failure or BPF execution fault was reproduced.
 
Yes, because it cannot happen.
 
>  mm/execmem.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/execmem.c b/mm/execmem.c
> index 349cadd874863a8b82052470e3b0e7b0df2e0ba7..4a48e9f445a02f783ca4dd501559cded54892dd8 100644
> --- a/mm/execmem.c
> +++ b/mm/execmem.c
> @@ -351,7 +351,9 @@ static int __execmem_cache_free(struct ma_state *mas, void *ptr, gfp_t gfp_mask)
>  		return err;
>  
>  	execmem_fill_trapping_insns(ptr, size);
> -	execmem_restore_rox(ptr, size);
> +	err = execmem_restore_rox(ptr, size);
> +	if (err)
> +		return err;
>  
>  	err = execmem_cache_add_locked(ptr, size, gfp_mask);
>  	if (err)
> 
> base-commit: 84abb955b1015477aa11a96e2f3ac1b938b77f48
> -- 
> 2.43.0

-- 
Sincerely yours,
Mike.