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@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.
>
> 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
