From: Dmitry Vyukov <dvyukov@google.com>
To: David Laight <David.Laight@aculab.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
Linus Torvalds <torvalds@linux-foundation.org>,
Matthew Wilcox <willy@infradead.org>,
"Tobin C. Harding" <me@tobin.cc>,
Kees Cook <keescook@chromium.org>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Linux-MM <linux-mm@kvack.org>,
syzbot
<bot+719398b443fd30155f92f2a888e749026c62b427@syzkaller.appspotmail.com>,
David Windsor <dave@nullcore.net>,
"keun-o.park@darkmatter.ae" <keun-o.park@darkmatter.ae>,
Laura Abbott <labbott@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Ingo Molnar <mingo@kernel.org>,
"syzkaller-bugs@googlegroups.com"
<syzkaller-bugs@googlegroups.com>,
Will Deacon <will.deacon@arm.com>
Subject: Re: BUG: bad usercopy in memdup_user
Date: Sun, 31 Dec 2017 09:11:05 +0100 [thread overview]
Message-ID: <CACT4Y+YBn2kJe3UE5T+zVgKCp-0hCgugTNE-EMw8B+Cy7ZQqKQ@mail.gmail.com> (raw)
In-Reply-To: <d6c8c26ba44847299c4db9136d60957d@AcuMS.aculab.com>
On Wed, Dec 20, 2017 at 10:44 AM, David Laight <David.Laight@aculab.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)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-12-31 8:11 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-18 13:40 syzbot
2017-12-18 14:22 ` Tetsuo Handa
2017-12-19 0:57 ` Kees Cook
2017-12-19 8:12 ` Dmitry Vyukov
2017-12-19 8:37 ` Tobin C. Harding
2017-12-19 8:41 ` Dmitry Vyukov
2017-12-19 9:04 ` Tobin C. Harding
2017-12-19 9:07 ` Dmitry Vyukov
2017-12-19 13:22 ` Matthew Wilcox
2017-12-19 13:41 ` Dmitry Vyukov
2017-12-19 14:08 ` Tetsuo Handa
2017-12-19 14:12 ` Dmitry Vyukov
2017-12-19 20:45 ` Tobin C. Harding
2017-12-19 20:33 ` Tobin C. Harding
2017-12-19 21:36 ` Linus Torvalds
2017-12-19 21:48 ` Al Viro
2017-12-19 22:09 ` Randy Dunlap
2017-12-19 23:24 ` Linus Torvalds
2017-12-20 3:50 ` Matthew Wilcox
2017-12-20 4:05 ` Linus Torvalds
2017-12-20 4:36 ` Linus Torvalds
2017-12-20 9:44 ` David Laight
2017-12-31 8:11 ` Dmitry Vyukov [this message]
2017-12-19 21:54 ` Kees Cook
2017-12-19 22:16 ` Matthew Wilcox
2017-12-19 22:24 ` Laura Abbott
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACT4Y+YBn2kJe3UE5T+zVgKCp-0hCgugTNE-EMw8B+Cy7ZQqKQ@mail.gmail.com \
--to=dvyukov@google.com \
--cc=David.Laight@aculab.com \
--cc=bot+719398b443fd30155f92f2a888e749026c62b427@syzkaller.appspotmail.com \
--cc=dave@nullcore.net \
--cc=keescook@chromium.org \
--cc=keun-o.park@darkmatter.ae \
--cc=labbott@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mark.rutland@arm.com \
--cc=me@tobin.cc \
--cc=mingo@kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=syzkaller-bugs@googlegroups.com \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
--cc=will.deacon@arm.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox