* [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