linux-kernel - Re: [PATCH -next v3] x86/dumpstack: Prevent KASAN false positive warnings in __show

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: <a15e3b40-f387-45be-afaa-a8a87bfb9e45@huaweicloud.com>
Date: Mon, 22 Sep 2025 21:11:08 +0800
From: Tengda Wu <wutengda@...weicloud.com>
To: Borislav Petkov <bp@...en8.de>
Cc: x86@...nel.org, jpoimboe@...nel.org,
 Andrey Ryabinin <ryabinin.a.a@...il.com>,
 Dave Hansen <dave.hansen@...ux.intel.com>,
 Thomas Gleixner <tglx@...utronix.de>, Alexander Potapenko
 <glider@...gle.com>, Andrey Konovalov <andreyknvl@...il.com>,
 Dmitry Vyukov <dvyukov@...gle.com>, Ingo Molnar <mingo@...hat.com>,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH -next v3] x86/dumpstack: Prevent KASAN false positive
 warnings in __show_regs



On 2025/9/22 20:28, Borislav Petkov wrote:
> On Mon, Sep 22, 2025 at 08:14:50PM +0800, Tengda Wu wrote:
>> Running 'echo t > /proc/sysrq-trigger' will trigger this type of asynchronous
>> stack walk, as demonstrated in the use case provided below.
> 
> So lead with that please.
> 
>>>> [332706.552324] BUG: KASAN: out-of-bounds in __show_regs+0x4b/0x340
>>>> [332706.552433] Read of size 8 at addr ffff88d24999fb20 by task sysrq_t_test.sh/3977032
>>>> [332706.552562]
>>>> [332706.552652] CPU: 36 PID: 3977032 Comm: sysrq_t_test.sh Kdump: loaded Not tainted 6.6.0+ #20
> 						^^^^^^^^^^^^^^
> 
> This doesn't help - it is some random script. Trigger this with the echo 't'
> ... thing.
> 
>> However, the main challenge with stopping the task first is that it fundamentally
>> alters the state we're trying to inspect. The primary use case for an asynchronous
>> stack walk is to diagnose a task that is already misbehaving (e.g., spinning in a
>> hard lockup, not responding to stops). If we need to stop a task to get its stack,
>> we might not be able to stop it at all, or the act of stopping it could change the
>> call stack, hiding the root cause of the issue.
>>
>> This is why my implementation selectively disables KASAN precisely for the async
>> walk scenario.
> 
> Add this to the commit message too. You need to explain it in such a way so
> that someone can use your instructions and reproduce it herself, without
> asking more questions. IOW, it needs to be perfectly clear what the issue is
> and what this is fixing.
> 
> Also, you don't have to rush your next version - we have a merge window coming
> up so this'll wait for the next round.
> 
> Thx.
> 

Will do. I'll revise the commit message with the needed details.

Thanks for the note on the timing. I'll hold it for the next round.

Best regards,
Tengda