Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763356AbdLSOMc (ORCPT ); Tue, 19 Dec 2017 09:12:32 -0500 Received: from mail-pl0-f47.google.com ([209.85.160.47]:46471 "EHLO mail-pl0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751084AbdLSOM0 (ORCPT ); Tue, 19 Dec 2017 09:12:26 -0500 X-Google-Smtp-Source: ACJfBouaY92Pifebn6RKObc33WEh+CLWbrEASgRjpCVN2SqqaUu3/OEQHYZXWFdGa5lOK30BWcKjCsfBmUAUxACI6/w= 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 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 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: 1987 Lines: 43 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.