From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f70.google.com (mail-pg0-f70.google.com [74.125.83.70]) by kanga.kvack.org (Postfix) with ESMTP id 574606B0033 for ; Tue, 19 Dec 2017 09:12:27 -0500 (EST) Received: by mail-pg0-f70.google.com with SMTP id z25so12608051pgu.18 for ; Tue, 19 Dec 2017 06:12: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 g6sor5063454plo.93.2017.12.19.06.12.26 for (Google Transport Security); Tue, 19 Dec 2017 06:12:26 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <201712192308.HJJ05711.SHQFVFLOMFOOJt@I-love.SAKURA.ne.jp> References: <20171219083746.GR19604@eros> <20171219132246.GD13680@bombadil.infradead.org> <201712192308.HJJ05711.SHQFVFLOMFOOJt@I-love.SAKURA.ne.jp> From: Dmitry Vyukov Date: Tue, 19 Dec 2017 15:12: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: Tetsuo Handa Cc: Matthew Wilcox , "Tobin C. Harding" , Kees Cook , 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 3:08 PM, Tetsuo Handa wrote: > Dmitry Vyukov wrote: >> 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. >> > Why not a kernel command line option? Hashing by default. Would work for continuous testing systems too. I just thought that since it has security implications, a config would be more reliable. Say if a particular distribution builds kernel without this config, then there is no way to enable it on the fly, intentionally or not. -- 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