[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200512034400.GA1537486@ZenIV.linux.org.uk>
Date: Tue, 12 May 2020 04:44:00 +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, May 12, 2020 at 02:09:01AM +0100, Al Viro wrote:
> 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.
Actually, more interesting question would be your /proc/cpuinfo...
Powered by blists - more mailing lists