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 6FC216B0272 for ; Tue, 19 Dec 2017 08:42:17 -0500 (EST) Received: by mail-pl0-f69.google.com with SMTP id g33so7459064plb.13 for ; Tue, 19 Dec 2017 05:42:17 -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 v62sor344642pgb.41.2017.12.19.05.42.16 for (Google Transport Security); Tue, 19 Dec 2017 05:42:16 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20171219132246.GD13680@bombadil.infradead.org> References: <001a113e9ca8a3affd05609d7ccf@google.com> <6a50d160-56d0-29f9-cfed-6c9202140b43@I-love.SAKURA.ne.jp> <20171219083746.GR19604@eros> <20171219132246.GD13680@bombadil.infradead.org> From: Dmitry Vyukov Date: Tue, 19 Dec 2017 14:41:55 +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: Matthew Wilcox Cc: "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 Tue, Dec 19, 2017 at 2:22 PM, Matthew Wilcox wrote: >> > >> This BUG is reporting >> > >> >> > >> [ 26.089789] usercopy: kernel memory overwrite attempt detected to 0000000022a5b430 (kmalloc-1024) (1024 bytes) >> > >> >> > >> line. But isn't 0000000022a5b430 strange for kmalloc(1024, GFP_KERNEL)ed kernel address? >> > > >> > > The address is hashed (see the %p threads for 4.15). >> > >> > >> > +Tobin, is there a way to disable hashing entirely? The only >> > designation of syzbot is providing crash reports to kernel developers >> > with as much info as possible. It's fine for it to leak whatever. >> >> We have new specifier %px to print addresses in hex if leaking info is >> not a worry. > > Could we have a way to know that the printed address is hashed and not just > a pointer getting completely scrogged? Perhaps prefix it with ... a hash! > So this line would look like: > > [ 26.089789] usercopy: kernel memory overwrite attempt detected to #0000000022a5b430 (kmalloc-1024) (1024 bytes) > > Or does that miss the point of hashing the address, so the attacker > thinks its a real address? If we do something with this, I would suggest that we just disable hashing. Any of the concerns that lead to hashed pointers are not applicable in this context, moreover they are harmful, cause confusion and make it harder to debug these bugs. That perfectly can be an opt-in CONFIG_DEBUG_INSECURE_BLA_BLA_BLA. -- 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