linux-kernel - Re: [RFC] kasan stack overflow warnings again: READ

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 PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 15 Feb 2017 23:31:57 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     "kasan-dev@...glegroups.com" <kasan-dev@...glegroups.com>,
        Andrey Ryabinin <aryabinin@...tuozzo.com>,
        Alexander Potapenko <glider@...gle.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Christian Borntraeger <borntraeger@...ibm.com>
Subject: Re: [RFC] kasan stack overflow warnings again: READ_ONCE(), typecheck()

On Wed, Feb 15, 2017 at 11:34 AM, Arnd Bergmann <arnd@...db.de> wrote:
> On Wed, Feb 15, 2017 at 10:18 AM, Dmitry Vyukov <dvyukov@...gle.com> wrote:
>> On Wed, Feb 15, 2017 at 12:03 AM, Arnd Bergmann <arnd@...db.de> wrote:

> My current estimate is only a handful of patches to enable
> CONFIG_FRAME_WARN=3072 with a clean build, and maybe a few dozen
> more to get down to 2048 with gcc-7.0.1 (no idea for older versions).
>
> What I'm looking at now is this set of remaining warnings (>3072 bytes)
> and 24 other files >2048:

I now found that most of the remaining ones go away when I make
CONFIG_KMEMCHECK depend on !KASAN_EXTRA (from my earlier patch).
Presumably this definition:

static __always_inline void *__inline_memcpy(void *to, const void
*from, size_t n)
{
        unsigned long d0, d1, d2;
        asm volatile("rep ; movsl\n\t"
                     "testb $2,%b4\n\t"
                     "je 1f\n\t"
                     "movsw\n"
                     "1:\ttestb $1,%b4\n\t"
                     "je 2f\n\t"
                     "movsb\n"
                     "2:"
                     : "=&c" (d0), "=&D" (d1), "=&S" (d2)
                     : "0" (n / 4), "q" (n), "1" ((long)to), "2" ((long)from)
                     : "memory");
        return to;
}

is the culprit when building with -fsanitize-address-use-after-scope

     Arnd