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: <i5f3iec7iprrqecr7r7wqhu5xl5cjujizwctsy3tphq2xzxck2@ieszua2sryec>
Date: Wed, 2 Jul 2025 12:49:10 +0100
From: Pedro Falcato <pfalcato@...e.de>
To: Shardul Bankar <shardulsb08@...il.com>
Cc: linux-kernel@...r.kernel.org, pmladek@...e.com, 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
Subject: Re: [BUG] KASAN: slab-out-of-bounds in vsnprintf triggered by large
 stack frame

On Tue, Jul 01, 2025 at 10:11:55PM +0530, 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.
> 
> 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
> 
>     pr_info("Final PoC: Triggering bug with controlled stack
> layout.\n");
> 
>     return -EAGAIN;
> }
> 
> static void __exit final_poc_exit(void) {}
> 
> module_init(final_poc_init);
> module_exit(final_poc_exit);
> MODULE_LICENSE("GPLv2");
> MODULE_DESCRIPTION("A PoC to trigger a kernel bug by creating a large
> stack frame.");
> 
>

There's no issue here. You're using an extremely buggy module with a huge local
variable that far exceeds the stack size, and proving it crashes. Like yeah, of
course it crashes, you gave it a broken module.

Kernel stacks do not expand. You're overwriting other memory in the direct map
with this. CONFIG_VMAP_STACK=y helps remedy this, but still only adds a single
page for the stack guard.

-- 
Pedro