linux-kernel - Re: [BUG] KASAN: slab-out-of-bounds in vsnprintf triggered by large stack frame

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]

Message-ID: <202507020716.1B1E38593@keescook>
Date: Wed, 2 Jul 2025 07:49:04 -0700
From: Kees Cook <kees@...nel.org>
To: Petr Mladek <pmladek@...e.com>
Cc: Shardul Bankar <shardulsb08@...il.com>, 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: [BUG] KASAN: slab-out-of-bounds in vsnprintf triggered by large
 stack frame

On Wed, Jul 02, 2025 at 02:00:55PM +0200, Petr Mladek wrote:
> Adding Kees and linux-hardening mailing list into CC just to be sure.
> 
> But I think that this is a bogus report, see below.
> 
> On Tue 2025-07-01 22:11:55, Shardul Bankar wrote:
> > Hello,
> > 
> > I would like to report a slab-out-of-bounds bug that can be reliably
> > reproduced with a purpose-built kernel module. This report was
> > initially sent to security@...nel.org, and I was advised to move it to
> > the public lists.
> > 
> > I have confirmed this issue still exists on the latest mainline kernel
> > (v6.16.0-rc4).
> > 
> > Bug Summary:
> > 
> > The bug is a KASAN-reported slab-out-of-bounds write within vsnprintf.
> > It appears to be caused by a latent memory corruption issue, likely
> > related to the names_cache slab.
> > 
> > The vulnerability can be triggered by loading a kernel module that
> > allocates an unusually large stack frame. When compiling the PoC
> > module, GCC explicitly warns about this: warning: the frame size of
> > 29760 bytes is larger than 2048 bytes. This "stack grooming" positions
> > the task's stack to overlap with a stale pointer from a freed
> > names_cache object. A subsequent call to pr_info() then uses this
> > corrupted value, leading to the out-of-bounds write.
> 
> Honestly, I think that everything works as expected.
> I do not see any bug with the existing kernel code.
> IMHO, the bug is in the test module, see below.
> 
> > Reproducer:
> > 
> > The following minimal kernel module reliably reproduces the crash on my
> > x86-64 test system.
> > 
> > #include <linux/init.h>
> > #include <linux/module.h>
> > #include <linux/printk.h>
> > 
> > #define STACK_FOOTPRINT (3677 * sizeof(void *))
> > 
> > static int __init final_poc_init(void)
> > {
> >     volatile char stack_eater[STACK_FOOTPRINT];
> >     stack_eater[0] = 'A'; // Prevent optimization
> 
> This takes the whole stack.

Way more than the whole stack. :) That's 29416 bytes and the default
stack is 8192 on x86_64. (Well, here it's actually 16K due to KASAN,
I think.) So this is well past the bottom of the stack. And since the
kernel builds with -fno-stack-clash-protection, we don't see a stack
probing crash as the stack usage crosses into the guard page. This is
the same as just doing:

static int __init final_poc_init(void)
{
	volatile char stack_eater;
	*(&stack_eater + STACK_FOOTPRINT) = 'A';
	...

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';
	...

:)

> >     pr_info("Final PoC: Triggering bug with controlled stack
> > layout.\n");
> 
> And any function called here, which would need to store return
> address on the stack would fail.
> 
> The compiler warned about it.
> KASAN caught and reported the problem.
> 
> The solution is to listen to the compiler warnings and
> do not create broken modules.

I would agree.

> > [  214.242355] Call Trace:
> > [  214.242356]  <TASK>
> > [  214.242359]  ? console_emit_next_record+0x12b/0x450
> [...]
> > [  214.242573]  ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
> > [  214.242575]  </TASK>

I would also note that the _entire_ trace is bogus too -- all the
leading "?" lines means it's just guessing based on what was left over
in memory rather than a sane dump.

> > This is my first time reporting a bug on the mailing list, so please
> > let me know if any additional information or formatting is required.

I'd repeat what Petr said, which is: if the compiler is emitting
warnings, then it's likely the bug is not with the core kernel. :)

-Kees

-- 
Kees Cook