Re: [PATCH v14 03/19] unwind_user/sframe: Store .sframe section data in per-mm maple tree

[Jens Remus <jremus@linux.ibm.com>]

On 5/6/2026 5:21 PM, Steven Rostedt wrote:
> On Wed, 6 May 2026 15:50:45 +0200
> Jens Remus <jremus@linux.ibm.com> wrote:

>>>> +static int __sframe_remove_section(struct mm_struct *mm,
>>>> +				   struct sframe_section *sec)
>>>> +{
>>>> +	if (!mtree_erase(&mm->sframe_mt, sec->text_start)) {
>>>> +		dbg("mtree_erase failed: text=%lx\n", sec->text_start);
>>>> +		return -EINVAL;
>>>> +	}
>>>> +
>>>> +	free_section(sec);
>>>> +
>>>> +	return 0;
>>>> +}
>>>> +
>>>>  int sframe_remove_section(unsigned long sframe_start)
>>>>  {
>>>> -	return -ENOSYS;
>>>> +	struct mm_struct *mm = current->mm;
>>>> +	struct sframe_section *sec;
>>>> +	unsigned long index = 0;
>>>> +	bool found = false;
>>>> +	int ret = 0;

	guard(srcu)(&sframe_srcu);

>>>> +
>>>> +	mt_for_each(&mm->sframe_mt, sec, index, ULONG_MAX) {
>>>> +		if (sec->sframe_start == sframe_start) {  
>>>
>>> Can concurrent calls to sframe_remove_section() cause a use-after-free and
>>> subsequent double free?
>>>
>>> mt_for_each() locklessly iterates mm->sframe_mt, and internally acquires and
>>> drops the RCU read lock, meaning the returned sec pointer has no lifetime
>>> protection in the loop body.
>>>
>>> If two threads concurrently invoke sframe_remove_section(), both could
>>> receive the exact same sec pointer from the tree. Thread A could then call
>>> __sframe_remove_section(), erasing the entry and freeing sec via
>>> free_section(). Thread B would then evaluate the if statement using the
>>> freed sec pointer, causing a use-after-free read, and potentially proceeding
>>> to free it again.  
>>
>> Please advise.
> 
> I guess it's asking if we should have a read_srcu_lock()?

Given __sframe_remove_section() does not schedule freeing of the section
and returns with -EINVAL if mtree_erase() fails there is no possibility
for a double-free.  Only one thread can succeed to mtree_erase().

Above change ensures that if two threads concurrently iterate the
sframe_mt in sframe_remove_section() they can both safely access
sec->sframe_start, as none of the sections will get freed until
return from sframe_remove_section().

Does that make sense?

Regards,
Jens
-- 
Jens Remus
Linux on Z Development (D3303)
jremus@de.ibm.com / jremus@linux.ibm.com

IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Ehningen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/