* [Query] Stack Overflow in "arch/arm/kernel/unwind.c" while unwinding frame
[not found] <CAPoNrtuuMn=Bm9Mo=PsJfJp6DMQaM-Eaz5An+0+DXL2=uObndg@mail.gmail.com>
@ 2013-09-24 6:28 ` Jean Pihet
2013-09-24 6:29 ` Anurag Aggarwal
2013-10-02 18:11 ` Catalin Marinas
0 siblings, 2 replies; 4+ messages in thread
From: Jean Pihet @ 2013-09-24 6:28 UTC (permalink / raw)
To: linux-arm-kernel
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 <anurag19aggarwal@gmail•com> 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 majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Query] Stack Overflow in "arch/arm/kernel/unwind.c" while unwinding frame
2013-09-24 6:28 ` [Query] Stack Overflow in "arch/arm/kernel/unwind.c" while unwinding frame Jean Pihet
@ 2013-09-24 6:29 ` Anurag Aggarwal
2013-10-02 18:11 ` Catalin Marinas
1 sibling, 0 replies; 4+ messages in thread
From: Anurag Aggarwal @ 2013-09-24 6:29 UTC (permalink / raw)
To: linux-arm-kernel
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 <jean.pihet@linaro•org> 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 <anurag19aggarwal@gmail•com> 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 majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
--
Anurag Aggarwal
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Query] Stack Overflow in "arch/arm/kernel/unwind.c" while unwinding frame
2013-09-24 6:28 ` [Query] Stack Overflow in "arch/arm/kernel/unwind.c" while unwinding frame Jean Pihet
2013-09-24 6:29 ` Anurag Aggarwal
@ 2013-10-02 18:11 ` Catalin Marinas
2013-10-06 7:14 ` Anurag Aggarwal
1 sibling, 1 reply; 4+ messages in thread
From: Catalin Marinas @ 2013-10-02 18:11 UTC (permalink / raw)
To: linux-arm-kernel
On 24 September 2013 07:23, Anurag Aggarwal <anurag19aggarwal@gmail•com> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Query] Stack Overflow in "arch/arm/kernel/unwind.c" while unwinding frame
2013-10-02 18:11 ` Catalin Marinas
@ 2013-10-06 7:14 ` Anurag Aggarwal
0 siblings, 0 replies; 4+ messages in thread
From: Anurag Aggarwal @ 2013-10-06 7:14 UTC (permalink / raw)
To: linux-arm-kernel
>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
<catalin.marinas@arm•com> wrote:
> On 24 September 2013 07:23, Anurag Aggarwal <anurag19aggarwal@gmail•com> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-10-06 7:14 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CAPoNrtuuMn=Bm9Mo=PsJfJp6DMQaM-Eaz5An+0+DXL2=uObndg@mail.gmail.com>
2013-09-24 6:28 ` [Query] Stack Overflow in "arch/arm/kernel/unwind.c" while unwinding frame Jean Pihet
2013-09-24 6:29 ` Anurag Aggarwal
2013-10-02 18:11 ` Catalin Marinas
2013-10-06 7:14 ` Anurag Aggarwal
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox