From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl0-f69.google.com (mail-pl0-f69.google.com [209.85.160.69]) by kanga.kvack.org (Postfix) with ESMTP id D12446B0038 for ; Sun, 31 Dec 2017 03:11:27 -0500 (EST) Received: by mail-pl0-f69.google.com with SMTP id s12so27464281plp.11 for ; Sun, 31 Dec 2017 00:11:27 -0800 (PST) Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id r18sor1783960pgv.163.2017.12.31.00.11.26 for (Google Transport Security); Sun, 31 Dec 2017 00:11:26 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <001a113e9ca8a3affd05609d7ccf@google.com> <6a50d160-56d0-29f9-cfed-6c9202140b43@I-love.SAKURA.ne.jp> <20171219083746.GR19604@eros> <20171219132246.GD13680@bombadil.infradead.org> <20171219214849.GU21978@ZenIV.linux.org.uk> From: Dmitry Vyukov Date: Sun, 31 Dec 2017 09:11:05 +0100 Message-ID: Subject: Re: BUG: bad usercopy in memdup_user Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: To: David Laight Cc: Al Viro , Linus Torvalds , Matthew Wilcox , "Tobin C. Harding" , Kees Cook , Tetsuo Handa , Linux-MM , syzbot , David Windsor , "keun-o.park@darkmatter.ae" , Laura Abbott , LKML , Mark Rutland , Ingo Molnar , "syzkaller-bugs@googlegroups.com" , Will Deacon On Wed, Dec 20, 2017 at 10:44 AM, David Laight 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: email@kvack.org