From: Shardul Bankar <shardulsb08@gmail.com>
To: Kees Cook <kees@kernel.org>, Petr Mladek <pmladek@suse.com>
Cc: linux-kernel@vger.kernel.org, rostedt@goodmis.org,
john.ogness@linutronix.de, senozhatsky@chromium.org,
viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz,
linux-fsdevel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [UNDERSTOOD] KASAN: slab-out-of-bounds in vsnprintf triggered by large stack frame
Date: Thu, 03 Jul 2025 02:03:09 +0530 [thread overview]
Message-ID: <56091d9b2c9b4d565da7569a81d8b85f0f7d4c7b.camel@gmail.com> (raw)
In-Reply-To: <202507020716.1B1E38593@keescook>
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
prev parent reply other threads:[~2025-07-02 20:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-01 16:41 [BUG] " Shardul Bankar
2025-07-02 11:49 ` Pedro Falcato
2025-07-02 12:00 ` Petr Mladek
2025-07-02 14:49 ` Kees Cook
2025-07-02 20:33 ` Shardul Bankar [this message]
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=56091d9b2c9b4d565da7569a81d8b85f0f7d4c7b.camel@gmail.com \
--to=shardulsb08@gmail.com \
--cc=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=john.ogness@linutronix.de \
--cc=kees@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
--cc=viro@zeniv.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®