On Thu, 28 Aug 2025 11:27:00 -0400 "Liam R. Howlett" <Liam.Howlett@xxxxxxxxxx> wrote: > > Does this make sense? > > > > Perhaps it's the corruption part that I'm missing here. If the sframe > is corrupt, you are iterating over all elements and checking the start > address passed in against the section start. > > So if the section is corrupted then how can we depend on the > sec->sframe_start? > > And is the maple tree corrupted? I mean, the mappings to sframe_start > -> sec is still reliable, right? > > Looking at the storing code, you store text_start - text_end to sec, > presumably the text_start cannot be smaller than the sframe_start? Sorry, that's not what gets corrupted. I should have expanded on it. The sframe section is two tables that describe how to get the return address from text locations, much like how ORC works in the kernel. We get a start and end address of where the sframe exists (that has the two tables) and a start and end section of the text it represents. When I said "corrupted", I meant that the sframe tables are totally created by user space and can not be trusted. While reading the sframe tables, if there's any anomaly that is found, it is considered "corrupted". So no, the start and end of where the sframes are and where the text should be validated at the start (I need to check that we do ;-). But once we start reading the sframe tables, they could hold garbage, or have something in there that the kernel doesn't support. As soon as that is detected, it gets removed so that it isn't looked at again. -- Steve
