linux-kernel - Re: KASAN + CPU soft-hotplug = stack-out-of-bounds at cpuinfo_store

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] [day] [month] [year] [list]

Message-ID: <YZJlr50XQExl7NUg@FVFF77S0Q05N.cambridge.arm.com>
Date:   Mon, 15 Nov 2021 13:50:39 +0000
From:   Mark Rutland <mark.rutland@....com>
To:     Qian Cai <quic_qiancai@...cinc.com>,
        Valentin Schneider <valentin.schneider@....com>
Cc:     Will Deacon <will@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        linux-arm-kernel@...ts.infradead.org,
        Dmitry Vyukov <dvyukov@...gle.com>,
        linux-kernel@...r.kernel.org, kasan-dev@...glegroups.com
Subject: Re: KASAN + CPU soft-hotplug = stack-out-of-bounds at
 cpuinfo_store_cpu

On Mon, Nov 15, 2021 at 10:44:11AM +0000, Mark Rutland wrote:
> Hi,
> 
> On Fri, Nov 12, 2021 at 11:50:16PM -0500, Qian Cai wrote:
> > FYI, running CPU soft-hotplug with KASAN on arm64 defconfig will
> > always trigger a stack-out-of-bounds below. I am not right sure where
> > exactly KASAN pointed at, so I am just doing the brute-force
> > bisect. The progress so far:
> 
> From below it looks like this is on linux-next; I can reproduce this on
> v5.16-rc1 using your config, when hotplugging CPU0 back in.
> 
> We used to have issues with stale poison being left on the stack across a
> hotplug, and we fixed that with commit:
> 
>   e1b77c92981a5222 ("sched/kasan: remove stale KASAN poison after hotplug")
> 
> ... but it looks like we no longer call init_idle() for each hotplug since commit:
> 
>   f1a0a376ca0c4ef1 ("sched/core: Initialize the idle task with preemption disabled")
> 
> ... and so don't get the kasan_unpoison_task_stack() call which we want when
> bringing up a CPU, which we used to get by way of idle_thread_get() calling init_idle().
> 
> Adding a call to kasan_unpoison_task_stack(idle) within bringup_cpu() gets rid
> of that, and I reckon we want that explciitly *somewhere* on the CPU bringup
> path.

FWIW I sent that out as a patch:

https://lore.kernel.org/linux-arm-kernel/20211115113310.35693-1-mark.rutland@arm.com/

Thanks,
Mark.