linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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>

  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