linux-kernel - Re: BUG: bad usercopy in memdup

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] [day] [month] [year] [list]

Message-ID: <CACT4Y+YBn2kJe3UE5T+zVgKCp-0hCgugTNE-EMw8B+Cy7ZQqKQ@mail.gmail.com>
Date:   Sun, 31 Dec 2017 09:11:05 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     David Laight <David.Laight@...lab.com>
Cc:     Al Viro <viro@...iv.linux.org.uk>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Matthew Wilcox <willy@...radead.org>,
        "Tobin C. Harding" <me@...in.cc>,
        Kees Cook <keescook@...omium.org>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Linux-MM <linux-mm@...ck.org>,
        syzbot 
        <bot+719398b443fd30155f92f2a888e749026c62b427@...kaller.appspotmail.com>,
        David Windsor <dave@...lcore.net>,
        "keun-o.park@...kmatter.ae" <keun-o.park@...kmatter.ae>,
        Laura Abbott <labbott@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Mark Rutland <mark.rutland@....com>,
        Ingo Molnar <mingo@...nel.org>,
        "syzkaller-bugs@...glegroups.com" <syzkaller-bugs@...glegroups.com>,
        Will Deacon <will.deacon@....com>
Subject: Re: BUG: bad usercopy in memdup_user

On Wed, Dec 20, 2017 at 10:44 AM, David Laight <David.Laight@...lab.com> wrote:
> From: Al Viro
>> Sent: 19 December 2017 21:49
>> > I suspect that an "offset and size within the kernel object" value
>> > might make sense.  But what does the _pointer_ tell you?
>>
>> Well, for example seeing a 0xfffffffffffffff4 where a pointer to object
>> must have been is a pretty strong hint to start looking for a way for
>> that ERR_PTR(-ENOMEM) having ended up there...  Something like
>> 0x6e69622f7273752f is almost certainly a misplaced "/usr/bin", i.e. a
>> pathname overwriting whatever it ends up in, etc.  And yes, I have run
>> into both of those in real life.
>>
>> Debugging the situation when crap value has ended up in place of a
>> pointer is certainly a case where you do want to see what exactly has
>> ended up in there...
>
> I've certainly seen a lot of ascii in pointers (usually because the
> previous item has overrun).
> Although I suspect they'd appear in the fault frame - which hopefully
> carries real addresses.
>
> A compromise would be to hash the 'page' part of the address.
> On 64bit systems this is probably about 32 bits.
> It would still show whether pointers are user, kernel, vmalloc (etc)
> but without giving away the actual value.
> The page offset (12 bits) would show the alignment (etc).
>
> Including a per-boot random number would make it harder to generate
> 'rainbow tables' to reverse the hash.


Bad things on kmalloc-1024 are most likely caused by an invalid free
in pcrypt, it freed a pointer into a middle of a 1024 byte heap object
which was undetected by KASAN (now there is a patch for this in mm
tree) and later caused all kinds of bad things:
https://groups.google.com/forum/#!topic/syzkaller-bugs/NKn_ivoPOpk
https://patchwork.kernel.org/patch/10126761/

#syz dup: KASAN: use-after-free Read in __list_del_entry_valid (2)