From: Kees Cook <email@example.com> To: Jann Horn <firstname.lastname@example.org> Cc: Yu-cheng Yu <email@example.com>, Alexander Potapenko <firstname.lastname@example.org>, Thomas Gleixner <email@example.com>, Ingo Molnar <firstname.lastname@example.org>, Borislav Petkov <email@example.com>, "H. Peter Anvin" <firstname.lastname@example.org>, the arch/x86 maintainers <email@example.com>, Dave Hansen <firstname.lastname@example.org>, Al Viro <email@example.com>, Andrew Morton <firstname.lastname@example.org>, Alexey Dobriyan <email@example.com>, LKML <firstname.lastname@example.org>, email@example.com Subject: Re: [PATCH] fs/binfmt_elf.c: allocate initialized memory in fill_thread_core_info() Date: Tue, 21 Apr 2020 13:20:58 -0700 [thread overview] Message-ID: <202004211320.C2B3840@keescook> (raw) In-Reply-To: <CAG48ez0rWH+kQVFVwwrZHqbL5G5H7CEJ-_xYsF15Wo2RzrqDfg@mail.gmail.com> On Tue, Apr 21, 2020 at 06:16:25PM +0200, Jann Horn wrote: > On Tue, Apr 21, 2020 at 6:05 PM Yu-cheng Yu <firstname.lastname@example.org> wrote: > > On Tue, 2020-04-21 at 17:09 +0200, Jann Horn wrote: > > > +x86 folks > > > > > > (rest of thread is on lore > > > <https://email@example.com/>;, > > > with original bug report on github > > > <https://github.com/google/kmsan/issues/76>;) > > > > > > On Tue, Apr 21, 2020 at 2:54 PM Alexander Potapenko <firstname.lastname@example.org> wrote: > > > > On Tue, Apr 21, 2020 at 5:42 AM Al Viro <email@example.com> wrote: > > > > > On Mon, Apr 20, 2020 at 03:41:40PM -0700, Kees Cook wrote: > > > > > > On Mon, Apr 20, 2020 at 03:33:52PM -0700, Andrew Morton wrote: > > > > > > > On Sun, 19 Apr 2020 12:08:48 +0200 firstname.lastname@example.org wrote: > > > > > > > > > > > > > > > KMSAN reported uninitialized data being written to disk when dumping > > > > > > > > core. As a result, several kilobytes of kmalloc memory may be written to > > > > > > > > the core file and then read by a non-privileged user. > > > > > > > > > > > > Ewww. That's been there for 12 years. Did something change in > > > > > > regset_size() or regset->get()? Do you know what leaves the hole? > > > > > > > > > > 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. > > > > > > > > > > > > > Seems to be REGSET_XSTATE filled by xstateregs_get(). > > > > Is there a ptrace interface also using that function? > > > > > > It looks to me like the problem KMSAN found is that > > > copy_xstate_to_kernel() will not fill out memory for unused xstates? I > > > think this may have been introduced by commit 91c3dba7dbc1 > > > ("x86/fpu/xstate: Fix PTRACE frames for XSAVES", introduced in v4.8). > > > > > > There seem to be no other functions that reach that path other than > > > coredumping; I think the correct fix would be to change > > > copy_xstate_to_kernel() to always fully initialize the output buffer. > > > > Yes, that makes sense. On the other hand, the kzalloc() fix prevents potential > > similar problems for other regsets. > > I don't really have anything against using kzalloc() there; but in my > opinion that's not a fix, that's hardening. The real problem, in my > opinion, is that regset->get() claims to have filled out a buffer > without actually having done so; and if someone happens to add another > caller to that thing in the future, I don't want them to run into > exactly the same problem again. Right -- we should fix both. -- Kees Cook
next prev parent reply other threads:[~2020-04-21 20:21 UTC|newest] Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-04-19 10:08 glider 2020-04-19 10:10 ` Alexander Potapenko 2020-04-20 22:33 ` Andrew Morton 2020-04-20 22:41 ` Kees Cook 2020-04-21 3:42 ` Al Viro 2020-04-21 8:14 ` Alexander Potapenko 2020-05-12 1:09 ` Al Viro 2020-05-12 3:44 ` Al Viro 2020-05-12 8:20 ` Alexander Potapenko 2020-05-13 3:33 ` Al Viro 2020-05-24 23:45 ` Al Viro 2020-05-26 22:38 ` Al Viro 2020-05-27 12:08 ` Alexander Potapenko 2020-05-27 19:04 ` Borislav Petkov 2020-05-27 19:53 ` Al Viro 2020-05-27 20:09 ` Borislav Petkov 2020-04-21 12:54 ` Alexander Potapenko 2020-04-21 15:09 ` Jann Horn 2020-04-21 16:04 ` Yu-cheng Yu 2020-04-21 16:16 ` Jann Horn 2020-04-21 16:26 ` Yu-cheng Yu 2020-04-21 20:20 ` Kees Cook [this message] 2020-04-21 8:06 ` Alexander Potapenko 2020-05-27 21:55 ` Kees Cook 2020-04-21 8:00 ` Alexander Potapenko
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=202004211320.C2B3840@keescook \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH] fs/binfmt_elf.c: allocate initialized memory in fill_thread_core_info()' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).