lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 19 Dec 2017 15:12:05 +0100 From: Dmitry Vyukov <dvyukov@...gle.com> To: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp> Cc: Matthew Wilcox <willy@...radead.org>, "Tobin C. Harding" <me@...in.cc>, Kees Cook <keescook@...omium.org>, Linux-MM <linux-mm@...ck.org>, syzbot <bot+719398b443fd30155f92f2a888e749026c62b427@...kaller.appspotmail.com>, David Windsor <dave@...lcore.net>, keun-o.park@...kmatter.ae, Laura Abbott <labbott@...hat.com>, LKML <linux-kernel@...r.kernel.org>, Mark Rutland <mark.rutland@....com>, Ingo Molnar <mingo@...nel.org>, syzkaller-bugs@...glegroups.com, Will Deacon <will.deacon@....com> Subject: Re: BUG: bad usercopy in memdup_user On Tue, Dec 19, 2017 at 3:08 PM, Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp> wrote: > Dmitry Vyukov wrote: >> On Tue, Dec 19, 2017 at 2:22 PM, Matthew Wilcox <willy@...radead.org> 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.
Powered by blists - more mailing lists