Hi All,
While executing unwind backtrace instructions in ARM, in the function
unwind_exec_insn()
there are chances that SP overflows from stack.
For example while executing instruction with opcode 0xAE, vsp can go
beyond stack to area that has not been allocated till now.
unsigned long *vsp = (unsigned long *)ctrl->vrs[SP];
int reg;
/* pop R4-R[4+bbb] */
for (reg = 4; reg <= 4 + (insn & 7); reg++)
ctrl->vrs[reg] = *vsp++;
The above scenario can happen while executing any of the unwind instruction.
One of the ways to fix the problem is to check for vsp with stack
limits before we increment it, but doing it for all the instructions
seems a little bad.
I just want to know that if anyone has faced the problem before
I am working on Linux kernel for Android phones and I saw one case
when this happened.
I am new to Linux Kernel so not sure if this is the right place to ask
the question.
--
Anurag Aggarwal
Hi,
Adding Russell and l.a.k ML.
Another question: is this linked to the following build warning?
CC arch/arm/kernel/return_address.o
arch/arm/kernel/return_address.c:63:2: warning: #warning "TODO:
return_address should use unwind tables"
Regards,
Jean
On 24 September 2013 07:23, Anurag Aggarwal <[email protected]> wrote:
> Hi All,
>
> While executing unwind backtrace instructions in ARM, in the function
> unwind_exec_insn()
> there are chances that SP overflows from stack.
>
>
> For example while executing instruction with opcode 0xAE, vsp can go
> beyond stack to area that has not been allocated till now.
>
> unsigned long *vsp = (unsigned long *)ctrl->vrs[SP];
> int reg;
>
> /* pop R4-R[4+bbb] */
> for (reg = 4; reg <= 4 + (insn & 7); reg++)
> ctrl->vrs[reg] = *vsp++;
>
> The above scenario can happen while executing any of the unwind instruction.
>
> One of the ways to fix the problem is to check for vsp with stack
> limits before we increment it, but doing it for all the instructions
> seems a little bad.
>
> I just want to know that if anyone has faced the problem before
>
> I am working on Linux kernel for Android phones and I saw one case
> when this happened.
>
> I am new to Linux Kernel so not sure if this is the right place to ask
> the question.
>
>
> --
> Anurag Aggarwal
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Hi Jean,
I don't think that it is related to the warning that you have suggested
On Tue, Sep 24, 2013 at 11:58 AM, Jean Pihet <[email protected]> wrote:
> Hi,
>
> Adding Russell and l.a.k ML.
>
> Another question: is this linked to the following build warning?
> CC arch/arm/kernel/return_address.o
> arch/arm/kernel/return_address.c:63:2: warning: #warning "TODO:
> return_address should use unwind tables"
>
> Regards,
> Jean
>
> On 24 September 2013 07:23, Anurag Aggarwal <[email protected]> wrote:
>> Hi All,
>>
>> While executing unwind backtrace instructions in ARM, in the function
>> unwind_exec_insn()
>> there are chances that SP overflows from stack.
>>
>>
>> For example while executing instruction with opcode 0xAE, vsp can go
>> beyond stack to area that has not been allocated till now.
>>
>> unsigned long *vsp = (unsigned long *)ctrl->vrs[SP];
>> int reg;
>>
>> /* pop R4-R[4+bbb] */
>> for (reg = 4; reg <= 4 + (insn & 7); reg++)
>> ctrl->vrs[reg] = *vsp++;
>>
>> The above scenario can happen while executing any of the unwind instruction.
>>
>> One of the ways to fix the problem is to check for vsp with stack
>> limits before we increment it, but doing it for all the instructions
>> seems a little bad.
>>
>> I just want to know that if anyone has faced the problem before
>>
>> I am working on Linux kernel for Android phones and I saw one case
>> when this happened.
>>
>> I am new to Linux Kernel so not sure if this is the right place to ask
>> the question.
>>
>>
>> --
>> Anurag Aggarwal
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
--
Anurag Aggarwal
On 24 September 2013 07:23, Anurag Aggarwal <[email protected]> wrote:
> While executing unwind backtrace instructions in ARM, in the function
> unwind_exec_insn()
> there are chances that SP overflows from stack.
>
>
> For example while executing instruction with opcode 0xAE, vsp can go
> beyond stack to area that has not been allocated till now.
>
> unsigned long *vsp = (unsigned long *)ctrl->vrs[SP];
> int reg;
>
> /* pop R4-R[4+bbb] */
> for (reg = 4; reg <= 4 + (insn & 7); reg++)
> ctrl->vrs[reg] = *vsp++;
>
> The above scenario can happen while executing any of the unwind instruction.
>
> One of the ways to fix the problem is to check for vsp with stack
> limits before we increment it, but doing it for all the instructions
> seems a little bad.
>
> I just want to know that if anyone has faced the problem before
I haven't seen it but I think with some stack (or unwind bytecode)
corruption it could happen.
I think we could place some checks only when vsp is assigned and return
-URC_FAILURE, together with some warning.
--
Catalin
>From what I saw, it happened when the next page is not mapped to
physical memory.
I don't think that stack corruption can cause this.
>From what I could understand about of the code there is not check if
the memory beyond stack is physically mapped or not.
To handle the problem I thought that checks can also be added in
unwind_exec_insn() function for stack overflow.
On Wed, Oct 2, 2013 at 11:41 PM, Catalin Marinas
<[email protected]> wrote:
> On 24 September 2013 07:23, Anurag Aggarwal <[email protected]> wrote:
>> While executing unwind backtrace instructions in ARM, in the function
>> unwind_exec_insn()
>> there are chances that SP overflows from stack.
>>
>>
>> For example while executing instruction with opcode 0xAE, vsp can go
>> beyond stack to area that has not been allocated till now.
>>
>> unsigned long *vsp = (unsigned long *)ctrl->vrs[SP];
>> int reg;
>>
>> /* pop R4-R[4+bbb] */
>> for (reg = 4; reg <= 4 + (insn & 7); reg++)
>> ctrl->vrs[reg] = *vsp++;
>>
>> The above scenario can happen while executing any of the unwind instruction.
>>
>> One of the ways to fix the problem is to check for vsp with stack
>> limits before we increment it, but doing it for all the instructions
>> seems a little bad.
>>
>> I just want to know that if anyone has faced the problem before
>
> I haven't seen it but I think with some stack (or unwind bytecode)
> corruption it could happen.
>
> I think we could place some checks only when vsp is assigned and return
> -URC_FAILURE, together with some warning.
>
> --
> Catalin
--
Anurag Aggarwal