All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Lin Yujun <linyujun809@huawei.com>
Cc: mhiramat@kernel.org, rostedt@goodmis.org, ardb@kernel.org,
	ndesaulniers@google.com, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH -next] arm/stacktrace, kasan: Silence KASAN warnings in unwind_frame()
Date: Wed, 30 Mar 2022 17:00:36 +0100	[thread overview]
Message-ID: <YkR+pL+aQ7M/s3U5@shell.armlinux.org.uk> (raw)
In-Reply-To: <20220317090751.80831-1-linyujun809@huawei.com>

On Thu, Mar 17, 2022 at 05:07:51PM +0800, Lin Yujun wrote:
> The following KASAN warning is detected by QEMU.
> 
> ==================================================================
> BUG: KASAN: stack-out-of-bounds in unwind_frame+0x508/0x870
> Read of size 4 at addr c36bba90 by task cat/163
> 
> CPU: 1 PID: 163 Comm: cat Not tainted 5.10.0-rc1 #40
> Hardware name: ARM-Versatile Express
> [<c0113fac>] (unwind_backtrace) from [<c010e71c>] (show_stack+0x10/0x14)
> [<c010e71c>] (show_stack) from [<c0b805b4>] (dump_stack+0x98/0xb0)
> [<c0b805b4>] (dump_stack) from [<c0b7d658>] (print_address_description.constprop.0+0x58/0x4bc)
> [<c0b7d658>] (print_address_description.constprop.0) from [<c031435c>] (kasan_report+0x154/0x170)
> [<c031435c>] (kasan_report) from [<c0113c44>] (unwind_frame+0x508/0x870)
> [<c0113c44>] (unwind_frame) from [<c010e298>] (__save_stack_trace+0x110/0x134)
> [<c010e298>] (__save_stack_trace) from [<c01ce0d8>] (stack_trace_save+0x8c/0xb4)
> [<c01ce0d8>] (stack_trace_save) from [<c0313520>] (kasan_set_track+0x38/0x60)
> [<c0313520>] (kasan_set_track) from [<c0314cb8>] (kasan_set_free_info+0x20/0x2c)
> [<c0314cb8>] (kasan_set_free_info) from [<c0313474>] (__kasan_slab_free+0xec/0x120)
> [<c0313474>] (__kasan_slab_free) from [<c0311e20>] (kmem_cache_free+0x7c/0x334)
> [<c0311e20>] (kmem_cache_free) from [<c01c35dc>] (rcu_core+0x390/0xccc)
> [<c01c35dc>] (rcu_core) from [<c01013a8>] (__do_softirq+0x180/0x518)
> [<c01013a8>] (__do_softirq) from [<c0135214>] (irq_exit+0x9c/0xe0)
> [<c0135214>] (irq_exit) from [<c01a40e4>] (__handle_domain_irq+0xb0/0x110)
> [<c01a40e4>] (__handle_domain_irq) from [<c0691248>] (gic_handle_irq+0xa0/0xb8)
> [<c0691248>] (gic_handle_irq) from [<c0100b0c>] (__irq_svc+0x6c/0x94)
> Exception stack(0xc36bb928 to 0xc36bb970)
> b920:                   c36bb9c0 00000000 c0126919 c0101228 c36bb9c0 b76d7730
> b940: c36b8000 c36bb9a0 c3335b00 c01ce0d8 00000003 c36bba3c c36bb940 c36bb978
> b960: c010e298 c011373c 60000013 ffffffff
> [<c0100b0c>] (__irq_svc) from [<c011373c>] (unwind_frame+0x0/0x870)
> [<c011373c>] (unwind_frame) from [<00000000>] (0x0)
> 
> The buggy address belongs to the page:
> page:(ptrval) refcount:0 mapcount:0 mapping:00000000 index:0x0 pfn:0x636bb
> flags: 0x0()
> raw: 00000000 00000000 ef867764 00000000 00000000 00000000 ffffffff 00000000
> page dumped because: kasan: bad access detected
> 
> addr c36bba90 is located in stack of task cat/163 at offset 48 in frame:
>  stack_trace_save+0x0/0xb4
> 
> this frame has 1 object:
>  [32, 48) 'trace'
> 
> Memory state around the buggy address:
>  c36bb980: f1 f1 f1 f1 00 04 f2 f2 00 00 f3 f3 00 00 00 00
>  c36bba00: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
> >c36bba80: 00 00 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
>                  ^
>  c36bbb00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  c36bbb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ==================================================================
> 
> There is a same issue on x86 and has been resolved by the commit f7d27c35ddff
> ("x86/mm, kasan: Silence KASAN warnings in get_wchan()").
> The solution could be applied to arm architecture too.
> 
> Signed-off-by: Lin Yujun <linyujun809@huawei.com>
> Reported-by: He Ying <heying24@huawei.com>

Hi,

Please drop this in the patch system if not already done so. Pointer to
it in my signature below. Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Lin Yujun <linyujun809@huawei.com>
Cc: mhiramat@kernel.org, rostedt@goodmis.org, ardb@kernel.org,
	ndesaulniers@google.com, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH -next] arm/stacktrace, kasan: Silence KASAN warnings in unwind_frame()
Date: Wed, 30 Mar 2022 17:00:36 +0100	[thread overview]
Message-ID: <YkR+pL+aQ7M/s3U5@shell.armlinux.org.uk> (raw)
In-Reply-To: <20220317090751.80831-1-linyujun809@huawei.com>

On Thu, Mar 17, 2022 at 05:07:51PM +0800, Lin Yujun wrote:
> The following KASAN warning is detected by QEMU.
> 
> ==================================================================
> BUG: KASAN: stack-out-of-bounds in unwind_frame+0x508/0x870
> Read of size 4 at addr c36bba90 by task cat/163
> 
> CPU: 1 PID: 163 Comm: cat Not tainted 5.10.0-rc1 #40
> Hardware name: ARM-Versatile Express
> [<c0113fac>] (unwind_backtrace) from [<c010e71c>] (show_stack+0x10/0x14)
> [<c010e71c>] (show_stack) from [<c0b805b4>] (dump_stack+0x98/0xb0)
> [<c0b805b4>] (dump_stack) from [<c0b7d658>] (print_address_description.constprop.0+0x58/0x4bc)
> [<c0b7d658>] (print_address_description.constprop.0) from [<c031435c>] (kasan_report+0x154/0x170)
> [<c031435c>] (kasan_report) from [<c0113c44>] (unwind_frame+0x508/0x870)
> [<c0113c44>] (unwind_frame) from [<c010e298>] (__save_stack_trace+0x110/0x134)
> [<c010e298>] (__save_stack_trace) from [<c01ce0d8>] (stack_trace_save+0x8c/0xb4)
> [<c01ce0d8>] (stack_trace_save) from [<c0313520>] (kasan_set_track+0x38/0x60)
> [<c0313520>] (kasan_set_track) from [<c0314cb8>] (kasan_set_free_info+0x20/0x2c)
> [<c0314cb8>] (kasan_set_free_info) from [<c0313474>] (__kasan_slab_free+0xec/0x120)
> [<c0313474>] (__kasan_slab_free) from [<c0311e20>] (kmem_cache_free+0x7c/0x334)
> [<c0311e20>] (kmem_cache_free) from [<c01c35dc>] (rcu_core+0x390/0xccc)
> [<c01c35dc>] (rcu_core) from [<c01013a8>] (__do_softirq+0x180/0x518)
> [<c01013a8>] (__do_softirq) from [<c0135214>] (irq_exit+0x9c/0xe0)
> [<c0135214>] (irq_exit) from [<c01a40e4>] (__handle_domain_irq+0xb0/0x110)
> [<c01a40e4>] (__handle_domain_irq) from [<c0691248>] (gic_handle_irq+0xa0/0xb8)
> [<c0691248>] (gic_handle_irq) from [<c0100b0c>] (__irq_svc+0x6c/0x94)
> Exception stack(0xc36bb928 to 0xc36bb970)
> b920:                   c36bb9c0 00000000 c0126919 c0101228 c36bb9c0 b76d7730
> b940: c36b8000 c36bb9a0 c3335b00 c01ce0d8 00000003 c36bba3c c36bb940 c36bb978
> b960: c010e298 c011373c 60000013 ffffffff
> [<c0100b0c>] (__irq_svc) from [<c011373c>] (unwind_frame+0x0/0x870)
> [<c011373c>] (unwind_frame) from [<00000000>] (0x0)
> 
> The buggy address belongs to the page:
> page:(ptrval) refcount:0 mapcount:0 mapping:00000000 index:0x0 pfn:0x636bb
> flags: 0x0()
> raw: 00000000 00000000 ef867764 00000000 00000000 00000000 ffffffff 00000000
> page dumped because: kasan: bad access detected
> 
> addr c36bba90 is located in stack of task cat/163 at offset 48 in frame:
>  stack_trace_save+0x0/0xb4
> 
> this frame has 1 object:
>  [32, 48) 'trace'
> 
> Memory state around the buggy address:
>  c36bb980: f1 f1 f1 f1 00 04 f2 f2 00 00 f3 f3 00 00 00 00
>  c36bba00: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
> >c36bba80: 00 00 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
>                  ^
>  c36bbb00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  c36bbb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ==================================================================
> 
> There is a same issue on x86 and has been resolved by the commit f7d27c35ddff
> ("x86/mm, kasan: Silence KASAN warnings in get_wchan()").
> The solution could be applied to arm architecture too.
> 
> Signed-off-by: Lin Yujun <linyujun809@huawei.com>
> Reported-by: He Ying <heying24@huawei.com>

Hi,

Please drop this in the patch system if not already done so. Pointer to
it in my signature below. Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

  reply	other threads:[~2022-03-30 16:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-17  9:07 [PATCH -next] arm/stacktrace, kasan: Silence KASAN warnings in unwind_frame() Lin Yujun
2022-03-17  9:07 ` Lin Yujun
2022-03-30 16:00 ` Russell King (Oracle) [this message]
2022-03-30 16:00   ` Russell King (Oracle)

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=YkR+pL+aQ7M/s3U5@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=ardb@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linyujun809@huawei.com \
    --cc=mhiramat@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=rostedt@goodmis.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.