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
