linux-kernel - Re: mmstress[1309]: segfault at 7f3d71a36ee8 ip 00007f3d77132bdf sp 00007f3d71a36ee8 error 4 in libc-2.27.so[7f3d77058000+1aa000]

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: <CAHk-=wgeHE7AS2Q4kPrkC5dMqfx_6+E84+FcEDYJSTugxqivUA@mail.gmail.com>
Date:   Thu, 22 Oct 2020 17:22:56 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Naresh Kamboju <naresh.kamboju@...aro.org>
Cc:     open list <linux-kernel@...r.kernel.org>,
        linux-m68k <linux-m68k@...ts.linux-m68k.org>,
        X86 ML <x86@...nel.org>, LTP List <ltp@...ts.linux.it>,
        lkft-triage@...ts.linaro.org,
        Linux-Next Mailing List <linux-next@...r.kernel.org>,
        linux-mm <linux-mm@...ck.org>,
        kasan-dev <kasan-dev@...glegroups.com>,
        Christian Brauner <christian.brauner@...ntu.com>,
        Ingo Molnar <mingo@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "Matthew Wilcox (Oracle)" <willy@...radead.org>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        zenglg.jy@...fujitsu.com, Stephen Rothwell <sfr@...b.auug.org.au>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Dmitry Vyukov <dvyukov@...gle.com>
Subject: Re: mmstress[1309]: segfault at 7f3d71a36ee8 ip 00007f3d77132bdf sp
 00007f3d71a36ee8 error 4 in libc-2.27.so[7f3d77058000+1aa000]

On Thu, Oct 22, 2020 at 5:11 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> In particular, I wonder if it's that KASAN causes some reload pattern,
> and the whole
>
>      register __typeof__(*(ptr)) __val_pu asm("%"_ASM_AX);
> ..
>      asm volatile(.. "r" (__val_pu) ..)
>
> thing causes problems.

That pattern isn't new (see the same pattern and the comment above get_user).

But our previous use of that pattern had it as an output of the asm,
and the new use is as an input. That obviously shouldn't matter, but
if it's some odd compiler code generation interaction, all bets are
off..

                Linus