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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 12 May 2020 02:09:01 +0100 From: Al Viro <viro@...iv.linux.org.uk> To: Alexander Potapenko <glider@...gle.com> Cc: Kees Cook <keescook@...omium.org>, Andrew Morton <akpm@...ux-foundation.org>, Alexey Dobriyan <adobriyan@...il.com>, LKML <linux-kernel@...r.kernel.org>, sunhaoyl@...look.com Subject: Re: [PATCH] fs/binfmt_elf.c: allocate initialized memory in fill_thread_core_info() On Tue, Apr 21, 2020 at 10:14:25AM +0200, Alexander Potapenko wrote: > > Not lately and I would also like to hear the details; which regset it is? > > Should be reasonably easy to find - just memset() the damn thing to something > > recognizable, do whatever triggers that KMSAN report and look at that > > resulting coredump. > > The bug is easily triggerable by the following program: > > ================================================ > int main() { > volatile char *c = 0; > (void)*c; > return 0; > } > ================================================ > > in my QEMU after I do `ulimit -c 10000`. .config, please - I hadn't been able to reproduce that on mine. Coredump obviously does happen, but not a trace of the poison is there - with your memset(data, 0xae, size) added, that is.
Powered by blists - more mailing lists