All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Jann Horn <jannh@google.com>
Cc: Yu-cheng Yu <yu-cheng.yu@intel.com>,
	Alexander Potapenko <glider@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Dave Hansen <dave.hansen@intel.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Andrew Morton <akpm@linux-foundation.org>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	sunhaoyl@outlook.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 <yu-cheng.yu@intel.com> wrote:
> > On Tue, 2020-04-21 at 17:09 +0200, Jann Horn wrote:
> > > +x86 folks
> > >
> > > (rest of thread is on lore
> > > <https://lore.kernel.org/lkml/20200419100848.63472-1-glider@google.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 <glider@google.com> wrote:
> > > > On Tue, Apr 21, 2020 at 5:42 AM Al Viro <viro@zeniv.linux.org.uk> 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 glider@google.com 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

  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 [PATCH] fs/binfmt_elf.c: allocate initialized memory in fill_thread_core_info() 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 \
    --to=keescook@chromium.org \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=glider@google.com \
    --cc=hpa@zytor.com \
    --cc=jannh@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=sunhaoyl@outlook.com \
    --cc=tglx@linutronix.de \
    --cc=viro@zeniv.linux.org.uk \
    --cc=x86@kernel.org \
    --cc=yu-cheng.yu@intel.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.