linux-hardening - Re: [syzbot] [mm?] [reiserfs?] kernel panic: stack is corrupted in ___slab

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]

Date:   Mon, 10 Jul 2023 09:52:58 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Vlastimil Babka <vbabka@...e.cz>
Cc:     "Lameter, Christopher" <cl@...amperecomputing.com>,
        David Rientjes <rientjes@...gle.com>,
        syzbot <syzbot+cf0693aee9ea61dda749@...kaller.appspotmail.com>,
        42.hyeyoo@...il.com, Andrew Morton <akpm@...ux-foundation.org>,
        iamjoonsoo.kim@....com, keescook@...omium.org,
        linux-fsdevel@...r.kernel.org, linux-hardening@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        penberg@...nel.org, reiserfs-devel@...r.kernel.org,
        roman.gushchin@...ux.dev, syzkaller-bugs@...glegroups.com,
        Jan Kara <jack@...e.cz>
Subject: Re: [syzbot] [mm?] [reiserfs?] kernel panic: stack is corrupted in ___slab_alloc

On Mon, 10 Jul 2023 at 09:48, Vlastimil Babka <vbabka@...e.cz> wrote:
>
> On 7/10/23 09:43, Dmitry Vyukov wrote:
> > On Thu, 6 Jul 2023 at 20:33, Lameter, Christopher
> > <cl@...amperecomputing.com> wrote:
> >>
> >> On Mon, 3 Jul 2023, Dmitry Vyukov wrote:
> >>
> >> >> This is happening during while mounting reiserfs, so I'm inclined to think
> >> >> it's more of a reisterfs issue than a slab allocator issue :/
> >>
> >> Have you tried to run with the "slub_debug" kernel option to figure out
> >> what got corrupted?
> >
> > Can slub_debug detect anything that KASAN can't?
>
> Probably not, KASAN will find out a bad write at the moment it happens,
> while slub_debug only later from corrupted red zone/poison.
>
> > I would assume KASAN can detect more bugs (e.g. stack/globals) and
> > report way better. And it was already enabled in the config.
>
> Anyway this is a stack corruption, not slab layout corruption. It's probably
> hard to distinguish a legitimate stack write from an overrun so even KASAN
> could not catch it immediately?

KASAN can detect stack out-of-bounds writes.
However, use-after-return detection support was never implemented in
KASAN (user-space ASAN can detect them as well).
User-space MSAN can also detect use-after-scope, I think it's not
implemented in KMSAN as well.

If we ever get to the root cause of this bug, it may be useful to
analyze why it wasn't detected and if it's possible to make such bugs
detected.