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

Message-ID: <d6c8c26ba44847299c4db9136d60957d@AcuMS.aculab.com>
Date:   Wed, 20 Dec 2017 09:44:00 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Al Viro' <viro@...IV.linux.org.uk>,
        Linus Torvalds <torvalds@...ux-foundation.org>
CC:     Matthew Wilcox <willy@...radead.org>,
        "Tobin C. Harding" <me@...in.cc>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        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

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.

	David