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

[Pedro Falcato]

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@xxxxxxxxxx, 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