Re: [PATCH v15 17/20] unwind_user/sframe: Separate reading of FRE from reading of FRE data words

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Critical] The `sframe_mt` maple tree is initialized without `MT_FLAGS_USE_RCU`. As a result, maple tree nodes are freed synchronously via `kmem_cache_free()` instead of being deferred by RCU. Lockless concurrent readers using `mtree_load()` (or `mt_for_each()`) can encounter a Use-After-Free if another thread concurrently executes `sframe_remove_section()`.
--

commit 9c045164b82cb49d5d976dfee059454643b1da0a
Author: Jens Remus <jremus@linux.ibm.com>

unwind_user/sframe: Separate reading of FRE from reading of FRE data words

__find_fre() performs linear search for a matching SFrame FRE for a given IP.
For that purpose it uses __read_fre(), which reads the whole FRE.

> diff --git a/kernel/unwind/sframe.c b/kernel/unwind/sframe.c
> index 48709f0bafc78..ec8318977a2ef 100644
> --- a/kernel/unwind/sframe.c
> +++ b/kernel/unwind/sframe.c
> @@ -39,6 +39,9 @@ struct sframe_fre_internal {
>  	u32		fp_ctl;
>  	s32		fp_off;
>  	u8		info;
> +	unsigned long	dw_addr;
> +	unsigned char	dw_count;
> +	unsigned char	dw_size;
>  };
>  
>  DEFINE_STATIC_SRCU(sframe_srcu);

[Severity: Critical]
This is a pre-existing issue, but I noticed that mm->sframe_mt is initialized
via the INIT_MM_SFRAME macro using MTREE_INIT(sframe_mt, 0), which explicitly
leaves out the MT_FLAGS_USE_RCU flag.

Since sframe_find() and sframe_remove_section() execute under the shared
sframe_srcu read lock here, there is no mutual exclusion between a concurrent
reader and writer.

Because MT_FLAGS_USE_RCU is absent, maple tree node deletions triggered by
mtree_erase() in __sframe_remove_section() synchronously free the nodes
via kmem_cache_free() without waiting for an RCU grace period.

Could this lead to a use-after-free if a lockless concurrent reader using
mtree_load() accesses internal tree nodes while a writer is concurrently
removing a section?

If a multithreaded userspace program triggers a stack unwind in one thread
while another concurrently removes a section via prctl, could this cause
memory corruption or kernel panics?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260520154004.3845823-1-jremus@linux.ibm.com?part=17