Re: [PATCH v14 12/19] unwind_user/sframe: Add .sframe validation option

Re: [PATCH v14 12/19] unwind_user/sframe: Add .sframe validation option

[Jens Remus]

On 5/5/2026 8:32 PM, sashiko-bot@kernel.org wrote:

>> diff --git a/kernel/unwind/sframe.c b/kernel/unwind/sframe.c
>> index 4419626f01734..45988cdc5c37a 100644
>> --- a/kernel/unwind/sframe.c
>> +++ b/kernel/unwind/sframe.c
> 
> [ ... ]
> 
>> +static int sframe_validate_section(struct sframe_section *sec)
>> +{
>> +	unsigned long prev_ip = 0;
>> +	unsigned int i;
>> +
>> +	for (i = 0; i < sec->num_fdes; i++) {
> 
> Can a maliciously crafted .sframe mapping with extremely large values for
> sec->num_fdes and fde.fres_num cause a soft lockup?
> 
> The outer and inner loops iterate over values parsed directly from the
> user-provided .sframe section header, which could be up to 4 billion.
> 
> Since there is no cond_resched() called within these loops, processing a
> large section might monopolize the CPU for an extended period and trigger
> the soft lockup watchdog. 
> 
>> +		struct sframe_fre_internal *fre, *prev_fre = NULL;
>> +		unsigned long ip, fre_addr;
>> +		struct sframe_fde_internal fde;
>> +		struct sframe_fre_internal fres[2];
>> +		bool which = false;
>> +		unsigned int j;
>> +		int ret;
>> +
>> +		ret = safe_read_fde(sec, i, &fde);
> 
> [ ... ]
> 
>> +		fre_addr = sec->fres_start + fde.fres_off;
>> +		for (j = 0; j < fde.fres_num; j++) {
>> +			int ret;
Steven, Josh,

concerning the questions raised by Sashiko AI review regarding crafted
.sframe with a large number of FDEs and/or FREs:

1. Could this trigger the hard lockup detector?

My understanding is this cannot occur, as neither unwinding nor the
optional validation are performed during NMI.


2. Could this trigger the soft lockup watchdog?

In the unwinding path binary search is performed for the FDE and linear
search for the FRE.  In the optional validation path (for debugging
purposes) both the FDE and FRE tables are iterated.  In both unwinding
and validation any detected invalidity stops the search/iteration.

FDE may not overlap; this is checked during validation and partially
during lookup.  FREs may not overlap either; this is checked during both
validation and lookup.  FDEs may share FDAs and FREs.  The maximum
number of FDEs is limited to 2^32-1.  The maximum number of FREs is
limited to 2^16-1 per FDE (due to the possibility for sharing).  Each
FDE/FRE must cover at least one byte of text.

For maliciously crafted .sframe to reach the maximum number of FDE of
2^32-1 a text of 4 GB is required, when having each FDE cover 1 byte.
To reach the maximum number of FRE of 2^16-1 only 64 KB of text is
required, when each FRE covers 1 byte.  To maximize on FDEs and FREs
4 GB of text could be represented using ~2^16 FDEs with shared
2^16-1 FREs each.

Given the wort case complexity of the validation is
O(#FDE) * O(log2(#FRE_per_FDE)), should it perform the following after
having processed a FDE including all of its potentially 2^16-1 FREs?

	if (need_resched())
		cond_resched();

What about the unwinding?  Given the worst case complexity is
O(log2(#FDE)) + O(#FRE_per_FDE), should it perform the above after
having performed the binary search for the FDE (before performing
the linear search for the FRE)?

Thanks and 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/

Re: [PATCH v14 12/19] unwind_user/sframe: Add .sframe validation option

[Steven Rostedt]

On Tue, 12 May 2026 16:23:34 +0200
Jens Remus <jremus@linux.ibm.com> wrote:

> Given the wort case complexity of the validation is
> O(#FDE) * O(log2(#FRE_per_FDE)), should it perform the following after
> having processed a FDE including all of its potentially 2^16-1 FREs?
> 
> 	if (need_resched())
> 		cond_resched();

BTW, you would only need:

	cond_resched();

as that checks need_resched(), no need to do it twice.

> 
> What about the unwinding?  Given the worst case complexity is
> O(log2(#FDE)) + O(#FRE_per_FDE), should it perform the above after
> having performed the binary search for the FDE (before performing
> the linear search for the FRE)?

That said, I'm holding off of adding new cond_resched() as PREEMPT_LAZY
is becoming the default, and there should be no more PREEMPT_NONE or
VOLUNTARY.

I think you can ignore this for now.

-- Steve