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

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

[shao.mingyin]

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.


 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

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

[Lorenzo Stoakes (ARM)]

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>

NAK.

this is generated by some AI slopper's script, spamming the kernel. The
patches I looked at were wrong/broken, so no to anything from this person.

They've sent 300 mails in under four weeks spanniing: ata, scsi, target,
ufs, nvme/nvmet, ubifs, ublk, zloop, dm, md, mmc, virtio-blk, mfd, gpio,
pwm, spi, PCI, ASoC, ACPI, net, vfs mount, block partitions, and now mm.

and 17 series across 7 subsystems over the past 23 hours.

We need a way to ban emails from people like this...

--
Cheers, Lorenzo