From: Kees Cook <keescook@chromium.org>
To: He Ying <heying24@huawei.com>
Cc: catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
sxwjean@gmail.com, peterz@infradead.org, paulus@samba.org,
npiggin@gmail.com, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] powerpc/process, kasan: Silence KASAN warnings in __get_wchan()
Date: Wed, 19 Jan 2022 10:51:34 -0800 [thread overview]
Message-ID: <202201191051.E49ED291@keescook> (raw)
In-Reply-To: <20220119015025.136902-1-heying24@huawei.com>
On Tue, Jan 18, 2022 at 08:50:25PM -0500, He Ying wrote:
> The following KASAN warning was reported in our kernel.
>
> BUG: KASAN: stack-out-of-bounds in get_wchan+0x188/0x250
> Read of size 4 at addr d216f958 by task ps/14437
>
> CPU: 3 PID: 14437 Comm: ps Tainted: G O 5.10.0 #1
> Call Trace:
> [daa63858] [c0654348] dump_stack+0x9c/0xe4 (unreliable)
> [daa63888] [c035cf0c] print_address_description.constprop.3+0x8c/0x570
> [daa63908] [c035d6bc] kasan_report+0x1ac/0x218
> [daa63948] [c00496e8] get_wchan+0x188/0x250
> [daa63978] [c0461ec8] do_task_stat+0xce8/0xe60
> [daa63b98] [c0455ac8] proc_single_show+0x98/0x170
> [daa63bc8] [c03cab8c] seq_read_iter+0x1ec/0x900
> [daa63c38] [c03cb47c] seq_read+0x1dc/0x290
> [daa63d68] [c037fc94] vfs_read+0x164/0x510
> [daa63ea8] [c03808e4] ksys_read+0x144/0x1d0
> [daa63f38] [c005b1dc] ret_from_syscall+0x0/0x38
> --- interrupt: c00 at 0x8fa8f4
> LR = 0x8fa8cc
>
> The buggy address belongs to the page:
> page:98ebcdd2 refcount:0 mapcount:0 mapping:00000000 index:0x2 pfn:0x1216f
> flags: 0x0()
> raw: 00000000 00000000 01010122 00000000 00000002 00000000 ffffffff 00000000
> raw: 00000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> d216f800: 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00
> d216f880: f2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >d216f900: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00
> ^
> d216f980: f2 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 00 00
> d216fa00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
> After looking into this issue, I find the buggy address belongs
> to the task stack region. It seems KASAN has something wrong.
> I look into the code of __get_wchan in x86 architecture and
> find the same issue has been resolved by the commit
> f7d27c35ddff ("x86/mm, kasan: Silence KASAN warnings in get_wchan()").
> The solution could be applied to powerpc architecture too.
>
> As Andrey Ryabinin said, get_wchan() is racy by design, it may
> access volatile stack of running task, thus it may access
> redzone in a stack frame and cause KASAN to warn about this.
>
> Use READ_ONCE_NOCHECK() to silence these warnings.
>
> Signed-off-by: He Ying <heying24@huawei.com>
Looks reasonable to me; thanks!
Reviewed-by: Kees Cook <keescook@chromium.org>
-Kees
> ---
> arch/powerpc/kernel/process.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> index 984813a4d5dc..a75d20f23dac 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -2160,12 +2160,12 @@ static unsigned long ___get_wchan(struct task_struct *p)
> return 0;
>
> do {
> - sp = *(unsigned long *)sp;
> + sp = READ_ONCE_NOCHECK(*(unsigned long *)sp);
> if (!validate_sp(sp, p, STACK_FRAME_OVERHEAD) ||
> task_is_running(p))
> return 0;
> if (count > 0) {
> - ip = ((unsigned long *)sp)[STACK_FRAME_LR_SAVE];
> + ip = READ_ONCE_NOCHECK(((unsigned long *)sp)[STACK_FRAME_LR_SAVE]);
> if (!in_sched_functions(ip))
> return ip;
> }
> --
> 2.17.1
>
--
Kees Cook
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: He Ying <heying24@huawei.com>
Cc: catalin.marinas@arm.com, mpe@ellerman.id.au,
benh@kernel.crashing.org, paulus@samba.org, npiggin@gmail.com,
christophe.leroy@csgroup.eu, sxwjean@gmail.com,
peterz@infradead.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] powerpc/process, kasan: Silence KASAN warnings in __get_wchan()
Date: Wed, 19 Jan 2022 10:51:34 -0800 [thread overview]
Message-ID: <202201191051.E49ED291@keescook> (raw)
In-Reply-To: <20220119015025.136902-1-heying24@huawei.com>
On Tue, Jan 18, 2022 at 08:50:25PM -0500, He Ying wrote:
> The following KASAN warning was reported in our kernel.
>
> BUG: KASAN: stack-out-of-bounds in get_wchan+0x188/0x250
> Read of size 4 at addr d216f958 by task ps/14437
>
> CPU: 3 PID: 14437 Comm: ps Tainted: G O 5.10.0 #1
> Call Trace:
> [daa63858] [c0654348] dump_stack+0x9c/0xe4 (unreliable)
> [daa63888] [c035cf0c] print_address_description.constprop.3+0x8c/0x570
> [daa63908] [c035d6bc] kasan_report+0x1ac/0x218
> [daa63948] [c00496e8] get_wchan+0x188/0x250
> [daa63978] [c0461ec8] do_task_stat+0xce8/0xe60
> [daa63b98] [c0455ac8] proc_single_show+0x98/0x170
> [daa63bc8] [c03cab8c] seq_read_iter+0x1ec/0x900
> [daa63c38] [c03cb47c] seq_read+0x1dc/0x290
> [daa63d68] [c037fc94] vfs_read+0x164/0x510
> [daa63ea8] [c03808e4] ksys_read+0x144/0x1d0
> [daa63f38] [c005b1dc] ret_from_syscall+0x0/0x38
> --- interrupt: c00 at 0x8fa8f4
> LR = 0x8fa8cc
>
> The buggy address belongs to the page:
> page:98ebcdd2 refcount:0 mapcount:0 mapping:00000000 index:0x2 pfn:0x1216f
> flags: 0x0()
> raw: 00000000 00000000 01010122 00000000 00000002 00000000 ffffffff 00000000
> raw: 00000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> d216f800: 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00
> d216f880: f2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >d216f900: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00
> ^
> d216f980: f2 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 00 00
> d216fa00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
> After looking into this issue, I find the buggy address belongs
> to the task stack region. It seems KASAN has something wrong.
> I look into the code of __get_wchan in x86 architecture and
> find the same issue has been resolved by the commit
> f7d27c35ddff ("x86/mm, kasan: Silence KASAN warnings in get_wchan()").
> The solution could be applied to powerpc architecture too.
>
> As Andrey Ryabinin said, get_wchan() is racy by design, it may
> access volatile stack of running task, thus it may access
> redzone in a stack frame and cause KASAN to warn about this.
>
> Use READ_ONCE_NOCHECK() to silence these warnings.
>
> Signed-off-by: He Ying <heying24@huawei.com>
Looks reasonable to me; thanks!
Reviewed-by: Kees Cook <keescook@chromium.org>
-Kees
> ---
> arch/powerpc/kernel/process.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> index 984813a4d5dc..a75d20f23dac 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -2160,12 +2160,12 @@ static unsigned long ___get_wchan(struct task_struct *p)
> return 0;
>
> do {
> - sp = *(unsigned long *)sp;
> + sp = READ_ONCE_NOCHECK(*(unsigned long *)sp);
> if (!validate_sp(sp, p, STACK_FRAME_OVERHEAD) ||
> task_is_running(p))
> return 0;
> if (count > 0) {
> - ip = ((unsigned long *)sp)[STACK_FRAME_LR_SAVE];
> + ip = READ_ONCE_NOCHECK(((unsigned long *)sp)[STACK_FRAME_LR_SAVE]);
> if (!in_sched_functions(ip))
> return ip;
> }
> --
> 2.17.1
>
--
Kees Cook
next prev parent reply other threads:[~2022-01-19 18:52 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-19 1:50 [PATCH] powerpc/process, kasan: Silence KASAN warnings in __get_wchan() He Ying
2022-01-19 1:50 ` He Ying
2022-01-19 18:51 ` Kees Cook [this message]
2022-01-19 18:51 ` Kees Cook
2022-01-21 1:44 ` [PATCH -v2] " He Ying
2022-01-21 1:44 ` He Ying
2022-02-17 8:20 ` He Ying
2022-02-17 8:20 ` He Ying
2022-06-09 14:44 ` Michael Ellerman
2022-06-09 14:44 ` Michael Ellerman
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=202201191051.E49ED291@keescook \
--to=keescook@chromium.org \
--cc=catalin.marinas@arm.com \
--cc=heying24@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=npiggin@gmail.com \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=sxwjean@gmail.com \
/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.