Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750997AbdLaIL2 (ORCPT ); Sun, 31 Dec 2017 03:11:28 -0500 Received: from mail-pg0-f42.google.com ([74.125.83.42]:33447 "EHLO mail-pg0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750739AbdLaIL1 (ORCPT ); Sun, 31 Dec 2017 03:11:27 -0500 X-Google-Smtp-Source: ACJfBotTq5MgjqsRSc574WQHjG43nmdxzi5mlksPhqQE3U+IOwGI0U+V0sDt4YX9+Xb7b6u7o09RcPDmowJleceF0AQ= 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 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1873 Lines: 40 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)