From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: perf/oprofile: fix off-by-one in stack check
Date: Tue, 8 Feb 2011 15:57:56 -0000 [thread overview]
Message-ID: <001401cbc7a8$f5dee5d0$e19cb170$@deacon@arm.com> (raw)
In-Reply-To: <1297138601-29895-1-git-send-email-rabin.vincent@stericsson.com>
Hi Rabin,
> Since it's fp - 1 that gets passed back in as tail in the next iteration, we
> need to ensure that fp - 1 is not the same as tail in order to avoid a
> potential infinite loop in the perf interrupt handler (which has been observed
> to occur). A similar fix seems to be needed in the OProfile code.
Hehe, that's a nasty loop to hit!
> Do we need to explicitly check for overflow (buftail.fp - 1 > buftail.fp)
> also? Though this should be already caught by the access check in the next
> iteration of the loop.
I don't think we need to worry about overflow for user backtracing
because the permissions should fail before we get that far.
> diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
> index 5efa264..dc885f0 100644
> --- a/arch/arm/kernel/perf_event.c
> +++ b/arch/arm/kernel/perf_event.c
> @@ -700,7 +700,7 @@ user_backtrace(struct frame_tail __user *tail,
> * Frame pointers should strictly progress back up the stack
> * (towards higher addresses).
> */
> - if (tail >= buftail.fp)
> + if (tail >= buftail.fp - 1)
> return NULL;
For a well formed fp chain, the terminating frame should have a saved
NULL frame pointer so it might be more obvious to do tail + 1 >= buftail.fp
(although I think it will work either way).
> return buftail.fp - 1;
> diff --git a/arch/arm/oprofile/common.c b/arch/arm/oprofile/common.c
> index 8aa9744..67b6b87 100644
> --- a/arch/arm/oprofile/common.c
> +++ b/arch/arm/oprofile/common.c
> @@ -85,7 +85,7 @@ static struct frame_tail* user_backtrace(struct frame_tail *tail)
>
> /* frame pointers should strictly progress back up the stack
> * (towards higher addresses) */
> - if (tail >= buftail[0].fp)
> + if (tail >= buftail[0].fp - 1)
> return NULL;
>
> return buftail[0].fp-1;
Same here.
Thanks,
Will
next prev parent reply other threads:[~2011-02-08 15:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-08 4:16 [PATCH] ARM: perf/oprofile: fix off-by-one in stack check Rabin Vincent
2011-02-08 15:57 ` Will Deacon [this message]
2011-02-09 3:56 ` [PATCHv2] " Rabin Vincent
2011-02-09 10:10 ` Will Deacon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='001401cbc7a8$f5dee5d0$e19cb170$@deacon@arm.com' \
--to=will.deacon@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.