linux-kernel - Re: [PATCH -next v2] riscv: add VMAP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 23 Jul 2021 12:29:25 +0800
From:   Jisheng Zhang <jszhang3@...l.ustc.edu.cn>
To:     tongtiangen <tongtiangen@...wei.com>
Cc:     Andreas Schwab <schwab@...ux-m68k.org>,
        Atish Patra <atishp@...shpatra.org>,
        Palmer Dabbelt <palmer@...belt.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org List" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -next v2] riscv: add VMAP_STACK overflow detection

On Fri, 23 Jul 2021 09:36:47 +0800
tongtiangen <tongtiangen@...wei.com> wrote:

> On 2021/7/23 7:54, Jisheng Zhang wrote:
> > On Thu, 22 Jul 2021 17:42:52 +0200
> > Andreas Schwab <schwab@...ux-m68k.org> wrote:
> >  
> >> On Jul 22 2021, Jisheng Zhang wrote:
> >>  
> >>> I think we need to pin the stack before calling get_wchan(), could you please
> >>> try below patch?  
> >>
> >> Thanks, this fixes the crash for me.
> >>
> >> Andreas.
> >>  
> >
> > Thanks for testing. I will send out formal patch later
> >
> > Thanks
> >
> > .
> >  
> 
> Hi all:
> I tried to reproduced this crash in openSUSE code repo（ 
> https://github.com/opensuse/kernel ）, but not reproduced successfully.
> 
>  From the patch of problem repair, the crash is due to task->stack is 
> released before calling get_wchan, the task state of maybe TASK_DEAD.
> 
> VMAP_STACK is used to detect kernel stack overflow, there is no 
> connection between the two, it makes me a little confused.

I believe the bug exists from the first day of riscv mainlined.

Since THREAD_INFO_IN_TASK=y in riscv, so when task stack can be freed
before being destroyed.

When VMAP_STACK=n, task's stack is allocated from linear mapping. When
task stack is freed, the corresponding mapping still exists, and since
get_wchan() only read, no harm is observed so far.

When VMAP_STACK=y, task's stack is allocated from vmalloc area. When
task stack is freed, the corresponding mapping may not exist, so I expect
MMU fault here, thus the kernel panic.

In summary, the bug isn't related with VMAP_STACK, but VMAP_STACK makes
the bug observable.

Thanks