[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <56091d9b2c9b4d565da7569a81d8b85f0f7d4c7b.camel@gmail.com>
Date: Thu, 03 Jul 2025 02:03:09 +0530
From: Shardul Bankar <shardulsb08@...il.com>
To: Kees Cook <kees@...nel.org>, Petr Mladek <pmladek@...e.com>
Cc: linux-kernel@...r.kernel.org, rostedt@...dmis.org,
john.ogness@...utronix.de, senozhatsky@...omium.org,
viro@...iv.linux.org.uk, brauner@...nel.org, jack@...e.cz,
linux-fsdevel@...r.kernel.org, linux-hardening@...r.kernel.org
Subject: Re: [UNDERSTOOD] KASAN: slab-out-of-bounds in vsnprintf triggered
by large stack frame
Hello all,
Thank you to Pedro, Petr, and Kees for taking the time to provide such
a detailed analysis and clarification. My apologies for the initial
misinterpretation.
I now understand that the issue reported is not a latent kernel bug,
but the expected and correct behavior when a module overflows its
fixed-size kernel stack. Your explanation that the KASAN report was a
direct symptom of this overflow, rather than the trigger of a separate
bug, was the key piece I was missing.
> Try this and see how the crash changes:
>
> static int __init final_poc_init(void)
> {
> volatile char stack_eater[STACK_FOOTPRINT];
> for (int i = STACK_FOOTPRINT - 1; i >= 0; i++)
> stack_eater[i] = 'A';
> ...
>
> :)
>
> >
As you suggested, Kees, I did try the PoC with the stack-clashing loop.
It was an insightful experiment, as it demonstrated how the specific
symptoms of the crash could change depending on exactly which memory
was corrupted by the overflow. It helped solidify my understanding of
the root cause.
I appreciate you all sharing your expertise and helping me learn from
this.
Thank you,
Shardul Bankar
Powered by blists - more mailing lists