diff mbox series

perf/hw_breakpoint: Fix arch_hw_breakpoint use-before-initialization

Message ID 20190906060115.9460-1-mark-pk.tsai@mediatek.com (mailing list archive)
State New, archived
Headers show
Series perf/hw_breakpoint: Fix arch_hw_breakpoint use-before-initialization | expand

Commit Message

Mark-PK Tsai (蔡沛剛) Sept. 6, 2019, 6:01 a.m. UTC
If we disable the compiler's auto-initialization feature
(-fplugin-arg-structleak_plugin-byref or -ftrivial-auto-var-init=pattern)
is disabled, arch_hw_breakpoint may be used before initialization after
the change 9a4903dde2c86.
(perf/hw_breakpoint: Split attribute parse and commit)

On our arm platform, the struct step_ctrl in arch_hw_breakpoint, which
used to be zero-initialized by kzalloc, may be used in
arch_install_hw_breakpoint without initialization.

Signed-off-by: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
Cc: YJ Chiang <yj.chiang@mediatek.com>
Cc: Alix Wu <alix.wu@mediatek.com>
---
 kernel/events/hw_breakpoint.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--
2.18.0

Comments

Doug Anderson Oct. 10, 2019, 5:44 p.m. UTC | #1
Hi,

On Thu, Sep 5, 2019 at 11:01 PM Mark-PK Tsai <mark-pk.tsai@mediatek.com> wrote:
>
> If we disable the compiler's auto-initialization feature
> (-fplugin-arg-structleak_plugin-byref or -ftrivial-auto-var-init=pattern)
> is disabled, arch_hw_breakpoint may be used before initialization after
> the change 9a4903dde2c86.
> (perf/hw_breakpoint: Split attribute parse and commit)
>
> On our arm platform, the struct step_ctrl in arch_hw_breakpoint, which
> used to be zero-initialized by kzalloc, may be used in
> arch_install_hw_breakpoint without initialization.
>
> Signed-off-by: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
> Cc: YJ Chiang <yj.chiang@mediatek.com>
> Cc: Alix Wu <alix.wu@mediatek.com>
> ---
>  kernel/events/hw_breakpoint.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Stable should pick this up, please.  It landed in mainline as commit
310aa0a25b33 ("perf/hw_breakpoint: Fix arch_hw_breakpoint
use-before-initialization").

* I have confirmed that it cleanly applies to and fixes a kernel based
on v4.19.75, so picking it back to kernels 4.19+ is the easiest.

* I have confirmed that my test shows that hardware breakpoints fail
on my arm32 test machine on v4.18.20 and on v4.17.0.  They last worked
on 4.16.  Picking this patch alone is not sufficient to make 4.17 and
4.18 work again.  Bisecting shows that the first breakage was the
merge resolution that happened in commit 2d074918fb15 ("Merge branch
'perf/urgent' into perf/core").  Specifically both parents of that
merge passed my test but the result of the merge didn't pass my test.
If anyone cares about 4.17 and 4.18 at this point, I will leave it as
an exercise to them to try to get them working again.

-Doug
Greg KH Oct. 16, 2019, 9:19 p.m. UTC | #2
On Thu, Oct 10, 2019 at 10:44:13AM -0700, Doug Anderson wrote:
> Hi,
> 
> On Thu, Sep 5, 2019 at 11:01 PM Mark-PK Tsai <mark-pk.tsai@mediatek.com> wrote:
> >
> > If we disable the compiler's auto-initialization feature
> > (-fplugin-arg-structleak_plugin-byref or -ftrivial-auto-var-init=pattern)
> > is disabled, arch_hw_breakpoint may be used before initialization after
> > the change 9a4903dde2c86.
> > (perf/hw_breakpoint: Split attribute parse and commit)
> >
> > On our arm platform, the struct step_ctrl in arch_hw_breakpoint, which
> > used to be zero-initialized by kzalloc, may be used in
> > arch_install_hw_breakpoint without initialization.
> >
> > Signed-off-by: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
> > Cc: YJ Chiang <yj.chiang@mediatek.com>
> > Cc: Alix Wu <alix.wu@mediatek.com>
> > ---
> >  kernel/events/hw_breakpoint.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> Stable should pick this up, please.  It landed in mainline as commit
> 310aa0a25b33 ("perf/hw_breakpoint: Fix arch_hw_breakpoint
> use-before-initialization").
> 
> * I have confirmed that it cleanly applies to and fixes a kernel based
> on v4.19.75, so picking it back to kernels 4.19+ is the easiest.
> 
> * I have confirmed that my test shows that hardware breakpoints fail
> on my arm32 test machine on v4.18.20 and on v4.17.0.  They last worked
> on 4.16.  Picking this patch alone is not sufficient to make 4.17 and
> 4.18 work again.  Bisecting shows that the first breakage was the
> merge resolution that happened in commit 2d074918fb15 ("Merge branch
> 'perf/urgent' into perf/core").  Specifically both parents of that
> merge passed my test but the result of the merge didn't pass my test.
> If anyone cares about 4.17 and 4.18 at this point, I will leave it as
> an exercise to them to try to get them working again.

Now queued up to 4.19.y, thanks.

greg k-h
diff mbox series

Patch

diff --git a/kernel/events/hw_breakpoint.c b/kernel/events/hw_breakpoint.c
index c5cd852fe86b..8fb842394924 100644
--- a/kernel/events/hw_breakpoint.c
+++ b/kernel/events/hw_breakpoint.c
@@ -413,7 +413,7 @@  static int hw_breakpoint_parse(struct perf_event *bp,

 int register_perf_hw_breakpoint(struct perf_event *bp)
 {
-	struct arch_hw_breakpoint hw;
+	struct arch_hw_breakpoint hw = {0};
 	int err;

 	err = reserve_bp_slot(bp);
@@ -461,7 +461,7 @@  int
 modify_user_hw_breakpoint_check(struct perf_event *bp, struct perf_event_attr *attr,
 			        bool check)
 {
-	struct arch_hw_breakpoint hw;
+	struct arch_hw_breakpoint hw = {0};
 	int err;

 	err = hw_breakpoint_parse(bp, attr, &hw);