Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935851AbdLSNmS (ORCPT ); Tue, 19 Dec 2017 08:42:18 -0500 Received: from mail-pf0-f180.google.com ([209.85.192.180]:47061 "EHLO mail-pf0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934436AbdLSNmQ (ORCPT ); Tue, 19 Dec 2017 08:42:16 -0500 X-Google-Smtp-Source: ACJfBouB2uqKBgV8UAnsDNhDaRgrURIQRJUlVZQnklUeuVuLPuieP6qeXow2LKgA3BFhbnt4pCT3yUIBhIyS5ZI08aU= 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 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 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: 1445 Lines: 31 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.